Собственно, уже слышал это мнение от всяких там разных Грефов и тд и тп. Не скажу, что это высказывают массово. Не скажу, что спрос на апкоклепателей (каким я являюсь, если че) падает. Но реально объективно уже столько всего понаписано, что вообще не понятно что еще пиплу надо. В общем, думаю, что скоро надо нам будет всем переливаться во что-то новое. Типа как было например, когда сдох J2ME. судя по всему не избежать матана и всяких там датасайнсов хотя бы на уровне более-менее осмысленного использования фреймворков. Кто что об этом думает? Понимаю, что тема немного политическая, и никто себя не считает бесполезным куском дерьма с бесполезными навыками, но попрошу от резких всяких высказываний удержаться, а больше поговорить содержательно.

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

1. во-первых создаю отдельный апп, где реализую таск. компилирую и включаю бинарник в основной проект.
2. алочу клауд инстанс на каком-нибудь провайдере (особо без разницы на каком, авс, гугл клауд, етс)
3. сетаплю по ремоут шелу жре
4. гружу бинарник
5. запускаю бинарник
6. апп на удаленном инстансе делает все дела, меняется данными с рут сервером по какому-нибудь протоколу типа акка, рми, хттп
7. ждем завершения удаленного аппа и прибиваем все ресуры на клауде.

собственно, о проблемах:

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

что есть по этому поводу в мире жабы или (даже лучше) скалы ? в идеале хотелось бы иметь что-то типа:

val executor: ExecutorService = RemoteExecutorFactory.create(someip,login,pass,initShellCommand)
executor.submit(new SomeTask)
executor.shutdown()
executor.awaitTermintion()

запилил очередной проект и после уже понял, что меня как-то подворачивает от того что у меня огромное количество типов написано в виде SomeInterface<SomeType>. собственно, все как бы и не сказать что плохо, но очевидно, что это несколько снижает уровень абстракции везде по коду. собственно, вопрос: а может это хорошая практика дописывать новые типы, чтобы избежать через чур большего количества использования дженериков? может есть какое-то золотое правило? я собственно понимаю, что дженерики как раз для того, чтобы типы не росли кобминаторно, но мы же все-таки пишем конкретные типы. на ум приходит правило что-то типа: во-первых, если не нужен дженерик именно из-за переменной типа, и мы пишем SomeInterface<SomeType> как миниму дважды, то есть смысл заколбасить SomeTypeSomeInterface. во-вторых, если SomeInterface<SomeType> имеет взаимнооднозначное соответсвествиее с каким-то конкретным SomeTypeSomeInterface, то от дженирика лучше избавиться.

в общем, буду рад услышать ваше мнение.

Может кто-нибудь подскажет сложно ли туда будет вкрутить нативный код (c/cpp) и гонять его по апи из жс?

Собственно, вопрос наверное вообще общий, но может есть какие-то специальные методы для конкретно жвм. Интересует как бороться с вылетом аппки по разным причинам: например, по OutOfMemoryException; ну или там даже какой сигнал системный придет, который захочет убить процесс. Коротко суть: как добиться чтобы процесс точно жил, или, как миниум, чтобы был максимально живуч.

есть несколько вопросов, которые вылезли практически сразу, не успев донести и первый мелкий проект до продакшена. может, кто-то поможет победить, а то скала нравится очень, но пока что есть боль.

вопросы на примере кода

package dao

import javax.inject.Inject

import model.FullKeyword
import play.api.db.slick.DatabaseConfigProvider
import slick.jdbc.JdbcProfile

import scala.concurrent.ExecutionContext

class DAO @Inject() (dbConfigProvider: DatabaseConfigProvider)(implicit ec: ExecutionContext) {
  private val dbConfig = dbConfigProvider.get[JdbcProfile]
  import dbConfig._
  import profile.api._
  import tables._

  def keywordById(id: Int) = db.run(keywords.filter(_.id === id).result).map(_.headOption)

  def linksByKeywordId(keywordId: Int) = db.run(links.filter(_.keywordId === keywordId).result)

  def imagesByKeywordId(keywordId: Int) = db.run(images.filter(_.keywordId === keywordId).result)

  def relatedByKeywordId(keywordId: Int) = db.run(relatedQueries.filter(_.keywordId === keywordId).result)

  def fullKeywordById(id: Int) = keywordById(id).map(_.map(keyword => {
    for {
      links <- linksByKeywordId(keyword.id)
      related <- relatedByKeywordId(keyword.id)
      images <- imagesByKeywordId(keyword.id)
    } yield(FullKeyword(keyword = keyword,links = links,related = related,images = images))
  }))

  def countKeywords = db.run(keywords.size.result)

  def keywordsNPart(n: Int,size: Int) = {
    val fromId = n*size + 1
    val toId = fromId + size
    db.run(keywords.filter(e => e.id >= fromId && e.id < toId).sortBy(_.id.asc).result)
  }
}

1. class DAO @Inject() (dbConfigProvider: DatabaseConfigProvider)(implicit ec: ExecutionContext) {
     private val dbConfig = dbConfigProvider.get[JdbcProfile]
   

   использую slick 3.2 и это в нем уже диприкейтед. свежее экзамплов не нашел. собственно, как же сейчас?

2.   private val dbConfig = dbConfigProvider.get[JdbcProfile]
   

   везде в экзамплах делают именно это: импортируют провайдер и вызывают у него .get[A]. я вижу здесь только противоречие IoC и ничего больше. в чем я не прав? не используется ни инициализация по требованию, никуда ниже компонентом провайдер тоже не передается, ну то есть нет в чем разумном их заподозрить.
3. сам апи выглядит довольно низкоуровневым:
   • везде пишешь эти db.run(query.filter(...).result), когда кажется нормальным что-то вроде query.filter(...).execute
   • импорт implicit из переменной dbConfig.profle.api._ `===` выглядит как копипаста, если писать много всяких DAO. это вообще нормально? выглядит как какой-то странный полиморфизм
   в целом, это все склеить как-то хочется.

4.   def linksByKeywordId(keywordId: Int) = db.run(links.filter(_.keywordId === keywordId).result)
   
     def imagesByKeywordId(keywordId: Int) = db.run(images.filter(_.keywordId === keywordId).result)
   
     def relatedByKeywordId(keywordId: Int) = db.run(relatedQueries.filter(_.keywordId === keywordId).result)
   

   вообще почти одинаковых три метода. как это сократить до def itemByKeywordId(item: TableQuery[?],keywordId: Int) и что за типы тут будут и где интерфейс для keywordId заимплиментить?

5.   def fullKeywordById(id: Int) = keywordById(id).map(_.map(keyword => {
       for {
         links <- linksByKeywordId(keyword.id)
         related <- relatedByKeywordId(keyword.id)
         images <- imagesByKeywordId(keyword.id)
       } yield(FullKeyword(keyword = keyword,links = links,related = related,images = images))
     }))
   

   тут вообще похоже на какой-то жаваскрипт получается. Future[Option[Future]] как сократить до Option[Future] ?

   и, как я понимаю, именно здесь и понадобился нам ExecutionContext, и мы завернули в кучу Future код, который оказался блокирующим. или зачем тут ExecutionContext ?

да и в целом класс получился как неймспес для методов. ООП тут точно нет. где тогда ФП и, конечно, где от него кайф?