• Большая игра на понижение крипты. Механизм финансовой катастрофы
    0
    дождется «глубокой» коррекции и зайдет обратно. Красавец!
  • Fullstack – почему это клево, или как получать от работы удовольствие
    +1
    Как-то все переусложнено и большая поляризация. Все зависит от нужд проекта и требований к Вам

    Я занимаюсь триатлоном и получаю от этого удовольствие пока от меня не требуют побеждать или быть впереди в отдельных заплывах или велогонках.
    Если в триатлоне я могу финишировать в первых 5-10%, то в отдельной велогонке я буду в первых 40-50%

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

    Я занимаюсь элементами:
    — стратегии
    — продукта
    — инфраструктуры
    — общего бекэнда
    — машинное обучение
    — аналитика

    Как результат:
    — недостаточно времени для погружения в исследования по продукту
    — я не умею нормально пользоваться утилитами производительности в linux и иногда дела решаются вертикальным масшабированием. Из примера, оказалась что мы около года запускали Mongo с неоптимальными параметрами диска и можно было сильно улучшить
    — когда раньше раз в год падал Kubernetes кластер, я не мог понять куда копать и просто создал новый
    — я потерял способность писать и читать аналитические sql запросы. Занимает время осмыслить новые функции
    — в перерыве работы с ML я забыл многие основы линейной алгебры, забыл специфики фреймворков.

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

  • Зачем человеку Scala?
    0
    то сейчас выглядит так, будто новый JVM проект и в самом деле стоит начинать на Kotlin

    Если у команды нет опыта на Scala, то может и стоит. В противном случае если есть экспертиза я не вижу смысла мигрировать на Kotlin.
    Я вижу большую проблему адаптации Scala с нуля, с очень большой фрагментацией подходов и стилей библиотек. Но если у команды есть обозначеный путь и политика в отношении выбора, то разработка становится очень продуктивной и сильно превосходит Kotlin с его пока еще неразвитой экосистемой
  • Зачем человеку Scala?
    +2
    Я соглашусь, Scala позволяет писать высоабстрактный и «совершенный» код и этим притягивает определенный круг разработчиков, но дальше все зависит от индивидуальности разработчиков и культуры команды.

    У нас, например, поощряется писать более простой код, хоть иногда и чуть больше, а иногда и чуть продублировать.

    Apache Spark со своим style guide пример как огромное количество котрибьютеров с разным бэкгроундом может работать над одной большой кодовой базой

    Twitter — отличный пример из индустрии, избегающий все упомянутые высокоабстрактные архитектуры и продолжающий с успехом использовать Scala
  • Maven. Собираем только измененное
    0
    Да, это альтернатива, не дополнение.

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

    Bazel — в свою очередь сравнимое с Pants
  • Maven. Собираем только измененное
    0
    В идеале: один репозиторий – один модуль.


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

    С описанным в статье нам в компании очень помогает Pants, там эта функциональность идет из коробки

    ./pants changed --include-dependees=transitive --changes-since=f61ad76d5d37d8dae6f1c298e1365af423d9892e
    

    Вот такой командой можно например получить список всех модулей, которые затронули изменения после определенного git коммита.

    Дальше для этих модулей мы можем выполнять тесты, собирать артефакты, если требуется и так далее.

    В результате имеем преимущества одного репозитория и сборка не страдает.
  • RPC, Messaging, REST: Терминология
    0
    Cинхронность RPC в настоящее время никак не предпочтительна. Насчет отличий Messaging, которые Вы приводите, согласен. Но Ваше (и мое) понятие этого термина существенно отличается от того, что приводится в этой статье.

    C картинки Messaging описывается как:

    Response GetPerson(Request request)

    В пример приводятся веб-сервисы, контракты и тд…
  • RPC, Messaging, REST: Терминология
    +2
    RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.

    Вы, наверное, можете сказать, что они ранние. RPC цветет и пахнет сейчас. CORBA и DCOM — не наиболее яркие предствители. Thrift, Produbuf с новым gRPC. Все вполне актуально…
    Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.

    Я не могу проследить тут логику. Кодогенерация RPC имплентацию за вас не сделает. Реализация транспорта (ненадежная, медленная, низкоскоростная среда) может быть отделена от сгенерированного кода и вообще не является проблемой присущей только RPC.
    Как именно помогает с этим Messaging?.. Чем контракты веб-сервисов с конвертами (видимо, подразумевается SOAP с его Envelope) отличется от контрактов (API) в RPC?
  • ОС для ЦОДов Mesosphere: Что это и для кого
    0
    Я извиняюсь за резкость. Просто для меня Mesosphere — как красная тряпка для быка. У кого-нибудь из присутствующих здесь, есть положительный опыт использования ЭТОГО в продакшне? Можете им поделиться?


    На данный момент, абстракции от самого Mesos вполне достаточны для построения staleless приложений. Например, «запустить N инстансов приложения на серверах, где есть для этого ресурсы» (Marathon, Aurora). Но когда я последний раз проверял это не настолько просто с сервисами, которые хранят данные на диске отдельно для каждого из инстансов (Cassandra, Elasticsearch). Если при падении stateless — сервисов, их можно перезапустить где угодно, то с базами данных все несколько сложнее и Mesos расширяется в данный момент до включения и управления дисковыми ресурсами.

    По моему опыту, довольно неплохо работают сервисы (имлементирующие Mesos фреймворк) хранящие данные, например, в Zookeeper. У нас неплохой опыт с развертыванием Storm кластера на Mesos. Остальное было пока на уровне экспериментов и тестов: Spark, Marathon, Chronos, но было вполне работоспособное.

    ОС для датацентра, конечно, звучит очень громко на данный момент, но это все вполне возможно и остается дело за реализацией, бОльшая часть которой будет основана на умной имлементации Mesos framework для каждого из интересующих сервисов
  • Новые виртуальные машины Microsoft Azure — SSD-диски, повышенная производительность и Buffer Pool Extensions
    +1
    Из письма, которое я получил
    Please note that the SSD drives in the D-series are non-persistent.

    Что делает практически невозможным разместить директорию с данными (Mongodb, Cassandra...) на них.
    Когда они перестанут быть временными?
  • Введение в sbt
    +1
    Из собственной практики, sbt в систему никогда не устанавливаю. Вместе этого кладу базовый скрипт в директорию проекта. Упрощает процесс запуска на других машинах, так как не требует дополнительных установок и версия указана непосредственно в системе контроля версий.

    Получается что для сборки проекта в системе необходима только Java.
  • Введение в sbt
    0
    То, на что дана ссылка в статье — введение. (Getting Started with sbt). Она делает довольно краткий и хороший обзор возможностей и основных концепций sbt.

    За подробностями можно обратиться в «sbt Reference Manual» www.scala-sbt.org/0.13/docs/index.html

  • Введение в sbt
    +1
    Как я понимаю, этот файл используется не только указанным Вами скриптом, но и launcher'ом, установка которого описана в системе. В системе может быть установлен sbt 0.13.0 а в build.properties указан 0.13.5. Тогда именно библиотеки последнего будут загружены при запуске и использоваться при сборке

    www.scala-sbt.org/0.13.2/docs/Community/Nightly-Builds.html
    remember that an sbt.version setting in <build-base>/project/build.properties determines the version of sbt to use in a project. If it is not present, the default version associated with the launcher is used.
  • Почему вы никогда не должны использовать MongoDB
    0
    Абсолютно согласен. Но разве на один из этих пунктов автор указывает?..
  • Почему вы никогда не должны использовать MongoDB
    +1
    будут те же самые «проблемы» только тогда, когда Вы попытается наложить реляционную структуру на них
  • Почему вы никогда не должны использовать MongoDB
    0
    С pymongo это можно сделать подключив нужный «son_manipulator», и «джойны» будут происходить автоматический на уровне «драйвера». Под Ruby тоже не должно быть такой проблемы.


    Не в этом дело. В любом случае, pymongo или что-либо другое будет сначала получать документ на клиент, смотреть на что он ссылается и подтягивать это следующими запросами.
  • Почему вы никогда не должны использовать MongoDB
    +3
    ACID транзакций и джоинов нет также и в Riak, Cassandra, HBase, что не делает их менее «продвинутыми».

  • Почему вы никогда не должны использовать MongoDB
    +14
    Заголовок абсолютно желтый. Нет ничего специфичного для MongoDB, кроме как конкретный попробованный пример документо-ориентированной базы данных. Такой критикой можно ударить по бОльшей части NoSQL продуктов, которые, как показывает практика, могут успешно использоваться и без непосредственной связи между таблицами.
  • Node.js не подходит для типовых веб-проектов
    0
    И объясните мне, пожалуйста. Если все-таки решение с потоками возможно для V8 через расширение, в чем смысл запуска eventloop на одном потоке? Почему нельзя его запустить на пуле из потоков (= число процессоров)? Какие у этого подхода недостатки в сравнении с кластером из такого же количества нодов?

    Потому что я вижу только преимущества.
    Что я упускаю?
  • Node.js не подходит для типовых веб-проектов
    +2
    Единственный контекст, под которым я обобщаю эти 2 понятия, — это вынос тяжелых задач за пределы основного event-loop. Да, эти threads-a-gogo можно считать решением. Хотя я не вижу активное развитие проекта. Код выглядит все также плохо.

    Вывод для меня: да, возможно. threads-a-gogo — хороший вариант. Однако, почему-то он не кажется нативным для node.js Еще одно расширение, написанное на C/C++

    Когда функционал базового V8, Fibers, Threads-a-gogo, Async объединится в единое решение и, что не менее важно, появится для этого хороший api — я смогу считать Node.js, как платформу, зрелой. Но это лишь будет достижением уровня JVM .NET Go и, может, чего-то другого…
  • Node.js не подходит для типовых веб-проектов
    0
    Под воркером я подразумевал cluster node.

    Воркеры, упомянутые Вами, похоже на те, что составляют worker queue. Так?

    Задача в 10-20 мс достойна выделенной очереди в таком случае?..

    «принцип построения асинхронных однопоточников» — даже звучит не очень. эту однопоточность я и подвергаю критике.

    Итак, для выноса cpu-intensive задач (еще довольно непонятно когда задача в node.js приобретает этот статус) возможны варианты:

    1. worker queue (здесь я подразумеваю и ответ после обработки)
    2. fibers — насколько я узнал это расширение возможностей V8. На 80% написана на С/С++. То, небольшое количество кусочков кода, приведенных в документации выглядят, мягко говоря, неуклюже. Сомневаюсь, что большинство вообще его использует.
  • Node.js не подходит для типовых веб-проектов
    0
    Вынес из контекста пары абзацев прямо под заголовком «Большие корпорации пока не используют Node.js»

    К C# я мало отношения имею. Но частенько пробегают статьи про его асинхронные механизмы.
    Тут и комментарий есть
    habrahabr.ru/post/191646/#comment_6657790

    О Java надо говорить не как о языке, а подразумевать JVM, как платформу со Scala, Clojure… Которые могут быть более элегантны, удобны и менее многословны, чем Node.js
  • Node.js не подходит для типовых веб-проектов
    +1
    И каким образом обычно происходит общение с этой внешеней программой? Система от этого перестает быть проще.

    > «В случае ноды можно забыть про многопоточность»

    Я люблю многопоточность. Забыть про локи, синхронизацию и т.д. можно и в других, более лучших средах.php

    Я программирую под JVM на Scala. Наша небольшая компания ни разу не энтерпрайз, я не посещаю семинары от Microsoft/Oracle, и я не усатый дядька.

    Если бы заголовок статьи был «Чем node.js лучше php», я бы ни сказал ни слова. Но не надо критиковать тут неповоротливость платформ JVM и .NET. Реализация событийной модели на них гораздо лучше. Верю, что и с Go дела обстоят также.
  • Node.js не подходит для типовых веб-проектов
    +2
    На это я обратил внимание в комментарии выше.

    > Так что другие клиенты просто пойдут на другие воркеры.

    Как они пойдут?.. Допустим, это будет round-robin…

    Как один нод узнает, что другой выполняет cpu-intensive work и возьмет работу на себя?

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

    Вы правда не согласны, что модель пула тредов внутри воркера более эффективна, чем однопоточная сущность nodejs?
    Я и сам поклонник async/non-blocking моделей, но не думаю, что это лучше делать на nodejs. Алетернатив достаточно…
  • Node.js не подходит для типовых веб-проектов
    +1
    не цепляйтесь конкретно за парсинг. Все, что я хочу сказать — это то, что любая cpu-intensive задача тормозит работу всего процесса (например, задерживает ответы клиентам)
  • Node.js не подходит для типовых веб-проектов
    +7
    После непродолжительного поиска попались статьи

    zef.me/4561/node-js-and-the-case-of-the-blocked-event-loop

    bitcartel.wordpress.com/2012/05/22/the-node-js-cpu-blocking-thing/

    В которых также критикуется однопоточность nodejs.

    По первой ссылке: парсинг 15mb json — 1.5 секунды. В более реальном примере пусть будет 150kb — 15ms.

    На эти самые 15 ms будут задержаны все ответы клиентам. И не важно сколько в таком случае nodejs будет поддерживать одновременных подключений, чем очень гордится. Я не вижу возможности отделить пул или хотя бы один поток для обслуживания событий запрсов-ответов клиентам. Даже модель кластера из воркеров не будет достаточно эффективна при подходе «по потоку на воркер».

    Тема кластера nodejs затрагивается по второй ссылке.

    "...Using Cluster looks simple, but if you’re a conscientious programmer, you now have a few things to worry about. For example “Forking a new worker when a death occurs” or “Monitoring worker health using message passing”. "

    И после всего, модуль Cluster — экспериментальный!

    И о какой зрелости проекта, упоминаемой в статье можно вести речь?..
  • Node.js не подходит для типовых веб-проектов
    0
    Согласен. Тем не менее, привзязанность воркера к одному потоку — это уже верхняя планка.

    Действительно ли в мире nodejs вообще нет (не предусмотрено/никогда не используются) блокирующих контекст (текущий поток) вызовов? Потому, как я понимаю, учитывая однопоточность, один такой вызов функции может заблокировать весь eventloop внутри воркера.
  • Node.js не подходит для типовых веб-проектов
    +1
    nodejs.org/api/cluster.html#cluster_cluster

    «A single instance of Node runs in a single thread. To take advantage of multi-core systems the user will sometimes want to launch a cluster of Node processes to handle the load.»

    Статус — Experimental (!)

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

    В статье был пример использования async для параллельного выполнения задач. Пусть это будут запросы к бд, например. Чтобы был прирост производительности от параллельного выполнения, все функции должны быть асинхронные и неблокирующие процесс. Даже с учетом того, что событийная модель реализована во всех драйверах (самый лучший случай!) для nodejs, все эта параллелизация будет выполняться в рамках одного процесса (узла кластера).

    Есть способ использовать ресурсы всех ядер?..
  • Google покупает Sparrow
    +2
    … Now we're joining the Gmail team to accomplish a bigger vision — one that we think we can better achieve with Google.
    ...Full speed ahead!

    Dom Leca, CEO

    Слова их CEO идут вразрез с Вашей напуганностью.
  • Заявка на домен.РУС подана в ICANN
    +5
    Кириллический домен РУС предназначен для продвижения языка, культуры и самобытности мирового русскоязычного сообщества.

    Это как же второй никому не нужный кириллистический домен будет способствовать продвижению культуры?!
  • Обзор Typesafe Stack 2.0 и введение в модель акторов на примере Akka 2.0
    0
    да
  • Обзор Typesafe Stack 2.0 и введение в модель акторов на примере Akka 2.0
    0
    Мы тоже, кстати, очень довольны использованием Play2. Но в нашей инфраструктуре приложения на нем являются клиентами для Finagle сервисов.
  • Обзор Typesafe Stack 2.0 и введение в модель акторов на примере Akka 2.0
    0
    кстати, letitcrash.com — блог команды Akka
  • Обзор Typesafe Stack 2.0 и введение в модель акторов на примере Akka 2.0
    +1
    Есть уже опыт применения на своих реальных проектах?
    Мы в Томском Политехническом начинали строить RPC-API на Akka2 + Google Protobuf. Добивались довольно хорошей параллелизации: на девелоперской машине htop показывал почти равномерную загрузку всех 8ми ядер на составной запрос.
    Но позже выяснилось, что для нашей специфики больше подходило Twitter Finagle + Thrift. Многие возможности Akka не использовались — все сводилось к асинхронным посылкам сообщений типа ask, редко one-way.
  • SOAP-сервер на Java при участии Apache CXF и Spring
    0
    Своим комментарием я по большей части делал акцент на мехазме описания soap — сервиса — то есть написании wsdl. Но что касается сообщений — можно взять просто Thrift, Protobuf или др. за основной механизм сериализации/десериализации.
  • SOAP-сервер на Java при участии Apache CXF и Spring
    0
    skillsmatter.com/podcast/design-architecture/enterprise-integration — недавно попалось. В связи с Вашим вопросом…
  • SOAP-сервер на Java при участии Apache CXF и Spring
    0
    Конечно, лучше платить программистам за написание километрового xml
  • SOAP-сервер на Java при участии Apache CXF и Spring
    +2
    извращенцы… :)
  • Возьми API, JavaScript; поди узнай скорей-ка, что в Файерфоксе нашем села батарейка!…
    +31
    Оба свойства — только для чтения.

    Возможность записи в navigator.battery.level была бы очень интересна… :)
  • MongoDB: Запросы
    +2
    простите, случайно в два одинаковых окна глянул