https://habrahabr.ru/company/haulmont/blog/283346/

Вот так вот.
Теперь платформа CUBA полная халява для разработки и продвижения.
Появились новые возможности для альтернативщиков.

(447) Универсальный - это чтобы с небольшими допилами и для сантехников подходил. Где, какие и за сколько готовы - просто другие характеристики.

(448) Ну так это проблема "известного банковского софта", а не явы, которая изначально предлагала все для свободной миграции. А точнее видимо "известных разработчиков" которые предложенные инструменты не использовала.

(447) + и с нормальной интеграцией с навигацией и картами а не тот изврат что есть

(450) юду? Тоже думал но там специфика тему тут поднимал

(453)+ Информатизация работы дворников, уборщиц и прочих муж/жена на час

(454)+ И халтурки кста для 1С-ников и прочих java'истов было бы удобно ))

(449) Да ну прямо так уж и разные. Все основные стандартизированы и легко получаются через System.getenv()

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

особый шик когда несколько версий JVM в системе и если оракл есть
от уровня костылестроения любой .Net программист сразу удавится :)

(455) И связать рейтинги - купил через сервис кошачий корм - получи заказ на работу дворником. И чтоб формирование рейтинга прозрачным было -  система дала именно мне заказ на мойку машины, так как я через нее пользовался вызовом ветеринара.

(457) Да java это костыль на костыле сидит и костылем из костылей погоняет...

(424) Java как раз позволяет не выходить на копеечный фриланс. Да, на проект попасть сложно, но если уже прошёл все испытания и собеседования, то на таком проекте можно долго кормиться хоть в местном бодишопе, хоть на удалёнке.

(458) На модерах разоримся или будет как в авито когда конторы под видом частников сначала полезут.
А потом исками и судами начнут за "омрачение деловой репутации" гнобить как различные черные/белые списки (работодателей и прочих)

ходил тут вчера на собеседование на андройд программиста, так...оценить свои знания :)) чувствовал себя жутким двоешником

сижу ща философию Java читаю :)))

(457) Интересно, а какая есть альтернатива для юниксов и ораклов у сишарп?

(462) ахахаха. На какую позицию собеседовался?

(464) написал же
<собеседование на андройд программиста>

Ничего страшного не спрашивали, тупо опыта коммерческого программинга не хватило.

(462) Лучше расскажи, что спрашивали

(465) Я имел ввиду junior, middle, senior.
(466) судя по всему не про устройство памятb в jvm )

(461) А списки закрытые. Ты видишь, что среди дворников город N, находящихся онлайн, ты сейчас на 3 месте, а вчера был на 5. Ты видишь, с чем связан этот прогресс, но других дворников (конкурентов) ты не видишь.

(468) Да но чтобы видеть историю выполненных работ/отзывы или еще что. ФИО и прочие то нафуй (152-ФЗ)

(469)+ И можно будет как гугл, яндекс и прочие, продавать места в списке :)

(467) Как раз про устройство памяти в JVM достаточно 1 статью прочитать, пусть и на английском языке. Вот всякие вопросы про алгоритмы и структуры данных - там да, читай не читай, вряд ли расскажешь, напишешь, если этого не изучал и к математике душа не лежит.

(471) " Как раз про устройство памяти в JVM достаточно 1 статью прочитать, пусть и на английском языке. " - что за статья такая?

Сборка мусора в ней описана? JMM, happens-before?!

какие структуры данных вызывают сложности?

(471) Для андроида важнее знать чем активити от вьювки отличаются и прочее а не всякие алгоритмы. Ну базовую яву понятно надо знать.

(471) Алгоритмы все дженериками сделаны. Их с нуля никто не пишет. Спрашивать должны про взаимодействие классов и фреймворки применяющиеся в кокретной разработке

(467) junior

спрашивали элементарщину честно говоря
Я ещё тупанул, надо было почитать перед походом туда, а я чёто както резко решился, записался вечером, утром уже пошёл туда :))

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

сказали читай теорию и приходи через пару месяцев, поговорим :)

(475) Это чисто андройдные вещи. У меня сегодня тоже было собеседование на другой проект в рамках компании. ))) Началось все с happens-before, volatile, как работают Atomic из пакета concurrent и т.д.

(475) А в резюме, что написано. Что вообще без опыта?

(470) Ни каких ФИО и проделанных работ.
В моей философии "Всё есть консультации".  Допустим, дворник города N ставит приложение на андроид. С утра проснулся, чаю попил, зашел в андроид и ставит статус "Готов проконсультировать". А другой гражданин, нуждающийся в уборке через то же приложение хочет получить консультацию дворника. Не услуги. Бесплатную консультацию. Типа: "Ага. Ну, у вас работы на два косаря, но можно и за один, если у вас своя метла". Встретятся ли они в реале и чем будут заниматься - не забота сервиса. И да, дворник может проплатить место в рейтинге за то, чтобы следующим утром оказаться  на первом месте и иметь возможность дать консультацию по уборке.

(472) Точную ссылку дать сейчас быстро не могу. Видел статью на сайте journaldev.com, Но она процентов на 90% повторяет по тексту такую же статью с ораклового сайта.

(480)
В одной статье говоришь?! http://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf

(479) Хм, тогда технически это обычный спецфорум для консультаций а никакой не фриланс-сервис.
Такое можно через ботов телеграм запилить легко.

(482)+ Заказчики/задачи и Исполнители (консультанты).
Общение в онлайне в несколько каналов (канал заказчика общий, канал задачи общий, приватные каналы заказчик-задача-консультант, канал консультанта общий).

Общие каналы читать могут другие, писать по разрешению (нечто вроде стены) но удалять только модераторы.
Приватные понятно дело приватные.
На общих каналах можно "прилеплять" сообщения/объявления.

(483) Да, несколько каналов. Заказчик (потребитель консультации) выбирает только канал. Он не выбирает исполнителя (нет такой функции). Сервис отправляет запрос на консультацию первому исполнителю в рейтинге канала и ждет N секунд/минут. Для каждого канала свои настройки. Для канала Дворники можно подождать и 5 минут, для канала Такси - 45 секунд и т.п.

Если первый в рейтинге не ответил (хотя поставил статус онлайн) сообщение идет второму и т.п. Первому приходит уведомление "Вы прошляпили вызов" и некоторое понижение в рейтинге. Всё, что от него требовалось - нажать кнопку "Подтверждаю" и оказать консультацию. Например, как из Выхино доехать в Коровино.

(484) С такси такой обзвон по рейтингу не прокатит, нужны фильтры по месту отправления и возможно по месту прибытия (не все согласны в ипеня или другую деревню везти).

(485) Конечно! Заказ идею первому по рейтингу с учетом отборов.

+(486) *идет

Реализацию серверной стороны я уже придумал. У меня сейчас хуже с клиентской стороной.

(483) У тебя сложная система. Представляешь, как геморно ее обновлять?
Есть такая штука - Redis, она целиком находится в оперативной памяти. Попробую реализовать такое на 1С. Пусть называется "Редиска". Один экземпляр 1С, всё находится в индексированных таблицах значения (ТЗ). Задача 1С - в фоновом режиме сохранять эту конструкцию, чтобы восстановить после краха. Достиг время взаимодействия со внешим миром 0,25 сек. Это конечно лучше, чем среднее время срабатыания web-сервиса или http-сервиса (более 3 секунд).

(484) А почему нельзя показывать запрос сразу всем ?
Просто, кто успевает ответить первым - того и тапки.
А также, вполне вероятно, что вопрошающего также будут интересовать другие мнения.

И вообще - когда пользователь выбрал канал, то его ещё неотправленное сообщение система рассылает в виде информации - намечается клиент - так проще, так как консультанты смогут проснуться раньше получения запроса, а кто-то может и заранее сказать, что он Offline, чтобы не разбазаривать рейтинг.

А хранить всё это дело в MySQL там есть режим DbInMemory

+(488) По идее такой подход уж точно можно использовать для прототипирования сервисов. Сервис получает JSON, отдает JSON. Заработало на 1С -  можно переносить на другие системы, например на mongodb.

(492) На самом деле, JSON или XML - не суть важно - те же самые данные. Держать всё в памяти - тоже не очень хорошее решение, так как наступает момент, когда памяти не хватает.
Конечно, если у нас один процесс, который все допрашивают, а он конвеерно обрабатывает запросы, то работать будет при не очень большом числе клиентов, так как очередь запросов, если сильно вырастет, то ей нужен будет отдельный процесс-диспетчер, чтобы можно было разбирать приоритеты и не заставлять всех ждать, если кто-то запросил всю базу сразу.

(493) Спасибо за ответ.
Я видел пример постороения запросов к серверу - если статус "Ок", то сразу возвращается результат. Если статус "ЗайдитеПозже" то возвращается ID запроса и следующий запрос нужно делать с этим ID через некий таймаут. То есть ничего нового уже не спрашивать, задать только ID старого запроса.

(493) Все намного проще с асинхронностью, очередь обработки запросов одна, но обработка запросов отдается на другие процессы/сервера а тот что принимает и отправляет ответ занят только этим.
Т.е. пришел запрос, отдаем его на выполнение другому процессу/серверу вместе с callback, и переходим к обработке следующего. Как оно будет готово получаем callback и данные отсылаются назад.
И никакие нафик приоритеты не нужны, нужен кластер серверов если нагрузка возрастает и этот кластер легко расширяется хоть до куда.

(495)+ Аналогично и храниться все это будет не в одной базе а в нескольких, а как сервер БД уже все это кешировать будет пофиг.
И главный плюс реализации через телеграм что отзывчивость (задержка между сообщениями от клиента заказчику и назад) общения обеспечивается легко при сохранении некой анонимности. По сути простой роутинг сообщений идет через бота по id юзеров.

(495) Нет, при катастрофическом росте запросов один процесс не справится - нужно будет иметь пул процессов.
Понятно, что исполнителей может быть много, но, если каждый запрос давать новому исполнителю, то никакой памяти не хватит, так как данные-то одни, и если все будут к ним ломиться, то на взаимоблокировках всё ляжет.
И callback - это тоже лишнее - право ответить на запрос можно передать тому, кто его исполняет.
(494) Это, конечно, хорошо - зайти позже, но лучше сделать имитацию двустороннего канала, чтобы тот, кто ждёт ответа только его ждал и не лез на сервер, чтобы узнать готов он или нет.

(496) как там написание tv? Идет? А то бы я бы купил.

(496) Нет, ну вы хотите ещё и стороннюю систему прикрутить - получается, что данные сначала должны будут быть переданными по ней, потом обработаны сервером, а потом опять отправлены в виде сообщений.

(498) Пока тестовая эксплуатация параллельно с юзанием TV который не сносим. До выхода на свет еще долго, одна проблема с железом $ много хотит.

(499) Да но сторонняя система висит на шустром канале и задержки минимальны. Причем система хорошо поддается распараллеливанию так как ничего страшного что запрос уйдет на другого консультанта по чуть старому рейтингу.
Вот как то сделать чтобы к консультантам уже "на связи" новые запросы (хотя он в топе) не поступали это вопрос.

ЗЫ Какой то аналог "ответов@майл.ру" выходит только в режиме онлайн без задержек...

(501) А что значит "на связи" ?
То есть, если кто-то "взял вопрос", то пока он не "закрыт", ему остальные не приходят ?
А как же распараллеливание ?

И, самый главный вопрос, как определить, что стороны закончили общение ?

(502) Приоритет отдается "свободным", вот если нет таких то можно и "уже занятому" скинуть.

(504) и в чём проблема - "клуша, скушавшая сыр, перемещается в конец списка" ?

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

(503) По таймауту отсутствия сообщений и статусам? Типа статус у консультанта "готов к труду и обороне" и общается = пока не посылаем, сменил статус за "занят, выполняю" выкидываем. Не сменил статус и сообщений/общения нету со скинутым кидаем еще заявки.

(505) Да, вполне вариант чтобы дать заработать другим с рейтингом похуже ))

(506) Согласен что очередь, но эту очередь из реализации самого сервиса приемо/передающего выносим наружу куда то на соседний сервер.

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

(509) Про монетизацию забыли, она тоже в критериях ))

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

(510) Так монетизация и есть рейтинг - или будут отдельные шкалы ?
Просто, если сервис не рассматривает вопрос оплаты (чтобы не отвечать по закону за качество работ), то есть только косвенные пути монетизации, например, за определённую сумму допускать несколько заданий сразу и т.п.

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

(511) В телеграме есть "программируемые клавиатуры", нажал и оно свободно с комментами.

Garykom, так ты уже в теме или пока планирование?)

(512) Ну да монетизация возможна с двух сторон и со стороны конультантов за несколько заданий или приоритет в предложении.
Так и со стороны запросодателей в обнулении монетизации от консультантов и приоритете запросов если консультантов маловато.

(515) Пока это стеб, чтобы реально заняться нужны ресурсы (время, деньги и прочие связи).

(517) Если консультантов мало, то система разворачивается - то есть будут висеть запросы, и консультант будет выбирать, какой взять, или мы за него будем.

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

(519) Дык разве кроме youdo.com есть конкуренты? Которые сильно ограничены территориально и по видам консультаций.

(520) кроме youdo.com я знаю только узкоспециализированные сайты.

(520) Сайтов для фрилансеров - полным полно.
Хотя, самый первый, наверное, irr.ru и самый популярный.

(520)+ Как раз через мессенджер типа телеграм легко и удобно раскрутиться.
Стоит уже у многих, вот еще нужно простой подбор консультантов сделать через "запрос обычным текстом" в чате к боту.
Хотя можно сделать меню на основе клавиатур программируемых.
А своя уникальная прога для сотовых и сайт это уже дело будущего.

Точно знаю только, что avito must die.

(524) Некоторые через группы в контакте задания размещают - тоже получается.

(522) Да согласен что полно но они заточены не на то.
Хочется в оперативности выигрывать и на рейтинге консультантов.

К примеру часто обращаются с консультациями по компам и прочему, причем не работа как таковая а именно консультации что купить (железо/софт) и/или к кому обратиться чтобы было то что им нуна и подешевше/получше.

(523) Месенждеров сейчас много - не все будут ставить месенджер только для того, чтобы что-то там заказать - так что нужен именно сайт, чтобы ничего не ставить.

Авито должен умереть. Они совсем зажрались.
(525) Да вконтактик вроде безвредный, пусть живет.

(525) Да группы ВК это в тему но только если там модеры овец не считают, часто висит такой хлам а последнее/свежее в самом конце куда листать замаешься.

(526) Консультации - это очень сложный вопрос - иногда получается, что вроде бы, всё было сказано правильно, а на той стороне неправильно поняли, и потом доказывай им, что верблюд не ты, а тот, кто читать не умеет.

(527) Да сайт нужен тоже, но через мессенджер оно реально удобнее и оперативнее.
Просто запустил и выбрал контакт/бота, вместо запуска браузера, авторизации и поиска там.

(530) Ыыы прямо мой случай когда нуна было купить переходник с новой видяхи к монику со старым кабелем DVI-VGA, а им дали обратный переходник со старой видяхи к монику с новым кабелем VGA-DVI

(531) На телефоне сайт как-то ещё работает, а вот месенджеры - или жрут батарейку, так как работа с памятью сделана некорректно, или оказывается, что он уже закрыт, когда ты ожидаешь, что получишь сообщение.

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

(533) Гм не наблюдал такого, весьма стабильно пашут причем несколько. Но я всякие вайберы/вацапы не жалую только скайп и телеграм.

(534) И не надо, это бот/сервис сделают. Прямой то передачи сообщений не будет между заказчиком и консультантом, только через бота или виртуальные учетки мессенджера.
Вот если они обменяются реальными это уже их дело.

(535) Вот как раз к скайпу и больше всего претензий про прожирание батареи, а так как у многих он почему-то считается стандартом из-за того, что идёт на компьютере и есть возможность проброса голоса в Ip-телефонию.

(537) Ну жрет но на день заряда аккума хватает, под конец правда уже процентов 40

(536) Просто, с помощью сайта, пользователь может войти как Вася и задать один вопрос, потом войти как Петя и задать другой - а через месенджер ему это будет сделать достаточно сложно.

(539) Если такое предусмотреть то не вижу проблем. Кнопочки/команды логин/выход в чатике.

(540)+ вот чтобы спайсами и лядями все не загадили это будет посложнее ))

(541) Получается, что все разговоры об анонимности системы - это пустые слова, так как оператор системы (администратор) будет знать любой чих любого пользователя.

(542) А без этого сча никак, вот представим что няня кому то головку отрежет, придут из органов и что сказать? А если не сказать то прикроют во избежание кучей способов.

(543) Ты показываешь данные, которые ввёл пользователь на сайте, а также список IP-адресов, с которых пользователь заходил - а дальше, они идут к тому, чьи Ip-адреса указаны и просят логи у него - и всё - меньше проблем для всех.
И никаких персональных данных.

И ещё одно в пользу сайта - когда ты регистрируешь сайт, то у него есть уникальное доменное имя, которое принадлежит тебе, а всякие боты в месенджере и т.п. прекрасно меняются на такие же боты владельцем месенджера.

(539) А если человек заходит с приложения андроида, то и проблемы быть не должно, если приложение знает номер телефона или откуда оно его знает? Оно знает хоть ID  устройства, на котором запущено? Или эти функции доступны только ЦРУ?

(546) <Оно знает хоть ID  устройства, на котором запущено?>
знает, но в андройде он сбрасывается при hardreset телефона
но imei можно получить...

тут уже всё от непосредственно приложения зависит, делает оно это или нет

(478) Да, без опыта

kotlin выживет ?

Еееее... мне сегодня предложили из одинэсников к java программерам перейти в отдел...

второй мой уход из 1С :))

Хто там говорил что в >30 лет нельзя в джуном пойти?