Pull to refresh
7
0
Send message

Я могу попробовать.
Главная выгода Agile для бизнеса:


  • быстрый выход на рынок
  • короткие фидбек циклы, что позволяет проводить быстрые эксперименты

Потому что:


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

В конкурентной среде (особенно такой динамичной, как в наши дни) у вотерфола почти нет шансов. Он непременно приведет к проваливанию сроков и разработке продукта, который, скорее всего, никому не нужен. Или, в лучшем случае, с огромным количеством фичей, которыми никто не пользуется.
Главная задача ИТ в динамичном бизнесе — не разработка софта, как бы странно это не звучало. Главная задача — решение бизнес проблем более эффективно. Оптимизация текущих процессов, изобретение новых. Если вы поговорите с вашим заказчиком и выясните, что он проводит огромное количество ручных вычислений, и вы дадите ему формулку для Excel, на написание которой и обучение нужных людей вам понадобится 2 дня, но это увеличит продуктивность заказчика на 90%, то вам цены не будет!

Недостаточно вы Скалу любите :)
Я видел энтузиастов, которые вообще текстовым редактором (Sublime, например) пользуются. В том числе люди, непосредсвенно причастные к разработке хардкорных Scala библиотек (cats, например).
Я лично (и большинство коллег) пользуюсь IDEA. Там своих глюков хватает. Иногда не может правильно определить возвращаемый тип, например. Такое случается при использовании сторонних библиотек со сложными типами и кучей implicits (тот же cats). Но мне Intellij как платформа очень нравится. Плюсов куда больше, чем минусов. Да и на Scala я и сам в текстовом редакторе готов писать, если б с IDE совсем дела были плохи.

Думается мне, что передача промиса актору так и напрашивается на проблемы.


  • Не совсем идиоматично для модели акторов, где акторы общаются посредством сообщений. Да, в приведенных примерах второй собеседник не актор, но в таком случае предполагается, что актор принимающий промис, знает, кто с ним общается. Но актору-то какое дело? Все, что он знает, — это какие типы сообщений он умеет обрабатывать. Промис трудно описать, как сообщение. Это как если бы вам прислали конверт с обратным адресом, вы положили туда письмо, но отправлять его по адресу не стали. Но откуда-то появилась невидимая рука и забрала письмо.
  • Одно из преимуществ акторов в akka — разделение имплементации и деплоймента. Т.е. актор может (и, возможно, должен) быть реализован так, что способ его установки и использования извне в самом акторе никак не упоминается. Но, если мы хотим заполнять промисы, присланные извне, мы должны гарантировать локальную установку актора.

Я бы использовал такой подход, только если использование ask сильно бьет по производительности (в чем есть сомнения) и если актор гарантированно локальный. Но если актор гарантированно локальный, то в чем смысл создания актора для заполнения промисов, который внутри выполняет неблокирующую функцию, возвращающую Future? Почему бы не положить эту функцию в обычный сервисный класс с понятным интерфейсом и не вызывать его напрямую?

Ну это ж на JVM всё-таки. Akka может быть лишь частью сложной системы. Да и сама Akka достаточно большая. Например, поддержка кластера позволяет строить сложные распределённые системы. Акторы лишь часть всего этого, хоть и фундаментальная.

Спасибо за статью. Хотел только добавить/поправить насчет параллелизма и настроек.


Строго говоря, "актор-на-поток" не является характеристикой Akka. Не уверен даже, можно ли это гарантировать. Akka лишь гарантирует синхронность обработки сообщений внутри актора, т.е. если клиент оправил конкретному актору N сообщений, порядок их получения и обработки актором гарантирован. Параллелизм же относительно других акторов и системы в целом определяется используемым "диспетчером" (фактически — пул потоков). Диспетчер присваивается каждому актору, и, если диспетчер не настроен для конкретного актора, используется дефолтный, который имеет под капотом ForkJoinPool, размер которого зависит, в том числе, от количества процессоров на машине. Короче говоря, может получиться так, что у вас меньше потоков в пуле потоков, чем количество акторов в пуле акторов. Особенно имеет смысл настроить отдельный диспетчер для акторов, которые выполняют долгие блокирующие операции, как в вашем примере, чтобы не загружать всю систему.


Akka очень хорошо настраиваема. В том числе, можно переместить конфигурацию конкретного роутера в файл конфигурации, что дает больше гибкости в настройке количества акторов в пуле, типа роутера, диспетчера и т.д.

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


public interface CreditService {
    Result<PaymentStatus> pay(int amount, CreditCard card);
}

Создание сущности Result<PaymentStatus> вне вызова метода, по-моему, только усложняет код. Метод pay должен быть в состоянии самостоятельно позаботиться о создании сущности Result<PaymentStatus>. И, кстати, такой подход лучше описывает интерфейс. Вполне очевидно, что в результате вызова метода мы получим отложенный результат и что метод сам по себе неблокирующий. Используя же в сигнатуре void не говорит ни о чем. void, вообще, должен только указывать на функции с побочными эффектами, что, в принципе, должно использоваться как можно реже.

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

image
Предлагаю посмотреть вот этот гайд: What's New in Java 8.
По-моему, отличное краткое руководство по нововведениям в Java 8, с простыми и понятными примерами, в которых видна разница (в сравнении с более старыми версиями) и практическая применимость.
Очень замечательно, что Вы проявляете интерес к описанной Вами теме, но, уж извините, если хотите показать пример использования языка программирования или технологии для решения каких-то задач, то, пожалуйста, делайте это более ответственно, не учите неопытных людей плохому. Огромные методы без комментариев, да ещё с бесконечными циклами с метками! Не закрываете соединяния с БД, при каждом обращении создаёте новое. Зачем вам платформозависимый скрипт для отсылки подтверждения регистрации? Зачем тогда Java?
Кстати, вы заметили, что шкала на оси у не соответствует сетке и точкам на графике? Я поэкспериментировал и не совсем понял, почему некоторые вещи работают так, а не иначе. Изначально вы добавляете на график 3 точки, потом показываете сцену, шкалы х и у выравниваются по этим 3-м точкам. у принимает максимальное значение 4.5, как и у вас на скриншоте. Затем вы добвляете ещё одну точку. И тут х, почему-то выравнивается, а у — нет. Если добавлять точку перед вызовом primaryStage.show(), всё отрисовывается хорошо. Поведение в принципе логичное, но не понятно, почему х выравнивается, а у — нет. Ещё интересный момент: задизейблил анимацию для графика — всё выравнивается как надо при любом порядке добавления 4-й точки.
Ну вот у меня Cinnamon стоит. Поэтому речь главным образом о нём шла :)
Хотелось бы, чтобы побыстрее добавили возможность размещать панель слева или справа. Предложение от пользователей на сайте комьюнити создано год назад. И статус его (Under dev. review) уже год как не меняется. Для меня одно из главных неудобств — панелька. Сама по себе сыровата (значки, надписи), так и удобнее (для меня) было бы разместить её слева.
Если бы не подзаголовок «Недостатки», я бы уже подумал, что автор кроме PHP больше ничего не видел — столько радости от каждой новой возможности. А наверное просто стиль повествования такой.
Ну а в целом выглядит на подобие многих других языков, что и хорошо, на мой взгляд. Единственное — необычно выглядят бэкслеши.
А вот ещё вспомнил. Когда я отсчитываю месяцы, этот прямоугльник в уме воображаю как бы с обратной стороны (может даже объёмная картинка получается), т.е. месяцы идут уже по часовой стрелке. А если просто воображать год (календарь), то прямоугольник будто на плоскости и выглядит как описано выше.
У меня, почему-то, календарь всегда ассоциировался с прямоугольником. Причём месяцы идут против часовой стрелки, зима сверху. И ещё — самое странное — верхняя и нижняя стороны (зима и лето) длиннее боковых. Возможно это потому, что весна и осень всегда воспринимаются как некие переходные поры года, а лето и зима как-бы основные — 2 крайности в погоде.
Ну и опять же. Причём здесь Raspberry Pi? :)
Так было бы лучше.
Если переводить дословно, получится что-то вроде «Java — это объектно-ориентированный язык программирования, созданный для запуска на разных операционных системах без необходимости перекомпиляции исходного кода.» Правда, так теряется немного смысл (хотя это и не отражено в оригинале), что же будет запускаться на разных ОС? Язык программирования?
Если писать коротко, то для большей ясности я бы написал как-нибудь так: «Java — объектно-ориетнированный язык программирования, исходный код которого компилируется в байт-код, который может быть запущен на любой платформе, для которой существует JVM, т.е. нет необходимости компилировать исходный код под целевую платформу». Разумеется, это не поймёт человек, не знающий, что такое JVM :)
Java, это язык объектно-ориентированного программирования для запуска исходного кода без необходимости комилляции под конкретную операционную систему.

А давно Java программы запускаются из исходного кода?
Получать информацию о пользователях из БД можно и без реализации дополнительных интерфейсов. Единственное, нужно будет объявить DataSource бин, через который Spring залезет в БД. А authentication-provider можно тогда объявить примерно так:

<authentication-provider>
    <jdbc-user-service data-source-ref="dataSource" 
                        users-by-username-query="select username, password, enabled 
                                                 from users where username = ?"
      			authorities-by-username-query="select u.username, au.authority 
                                                       from users u, authorities au  
                                                       where u.id = au.user_id and u.username = ?" />
</authentication-provider>

Т.е. нужно отдать Спрингу небольшой sql, который достанет из базы имя пользователя, пароль, флаг, не заблокирован ли пользователь, и роли пользователя.

Также авторизованный доступ можно вешать не только на URLы, но и на Java методы.
Как насчёт добавить на панель кнопку «Refresh» или что-то вроде того, чтобы можно было обновить информацию, не дожидаясь 5 минут (для тех, кто дома, и следит за ходом покупок)?
1

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Registered
Activity