Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×
Technical Solutions Architect
  • Как устроить ребенка в школу по месту жительства в Киеве без прописки?

    Мы в частные ходим уже пару лет как.

    А ты все еще на Филиппинах

    И да и нет.

  • Как устроить ребенка в школу по месту жительства в Киеве без прописки?

    А с прошлого года в школу берут только по официальному месту проживания

    О. я похоже многое пропустил. Это получается- хотят получить что то похожее как в америках. Чтобы цена дома зависела о качества школы к которой он приписан?

    ЗЫ. Алексей- привет!

    Підтримав: Alex Buzan
  • Разработка реактивных и распределенных систем с Vert.x

    На самом деле- минусов у vert.x тоже хватает.
    Я с этим vert.x — собаку съел. Но нужно понимать- что все описанные проблемы- это то что всплывает при реально очень больших нагрузках- порядка 1K rps.
    Из того что сразу могу назвать:

    1. Утечки памяти. Берем асинхронный клиент Redis идущий в поставке с vert.x. Шикарная вешь- отлично работает в асинхронном режиме с обычной кофигурацией Redis типа — vert.x клиент- редис. Но в случае- когда редис скофигурирован работать в Sentinel конфигурации, да и еще и под высокой нагрузкой — начинаются утечки памяти. Покопавшись в дебрях стектрейсов — понял что vertx redis client не сразу закрывает соединения- даже после того как код вышел за область исполнения redis related кода при возникновении таймаутов в запросах к редису. В свое время пришлось брать Jedis- так как он работает надежнее при любых нагрузках.
    2. Rx обертки для vert.x тоже текут- или я совсем не умею их готовить
    3. Писать код на колбеках — сложно. Еще сложнее потом это чинить и поддерживать/оптимизировать.
    4. Hazelcast — что используется для distributed event bus- отлично ведет себя на тестовых примерах- но в на больших нагрузках- создаёт проблемы:
    4.1. Надежность. Потерять сообщение? Легко.
    4.2. Несвоевременно освобождение сокетов? Обязательно.
    4.3. Конфигурация сокет пула- это отдельное приключение. Особенно — когда надо убедить Operations team- открыть порядка 1000 портов для общения между кластером vert.x- - та еще забава А это надо делать для каждой ноды в кластере.
    5. Непонятки с рандомными ошибками «port in use» — я так и не понял куда копать. То ли проблема в Hazelcast, или OS закрывает сокеты недостаточно быстро, а приложение уже закрыло и думает- что сокет освобожден и можно переиспользовать. Вообщем- хз.
    6. ЧАВО — нечаво. просто оставлю этот тут stackoverflow.com/questions/tagged/vert.x Создатель vert.x неподелил что то с stackoverflow и в итоге искать ответы на проблемы приходится в документации/исходниках и гугл группах но не на stackoverflow .
    7 Идея distributed vertices в эпоху k8s & docker — слишком переусложнена. Горизонтально смаштабировать приложение намного легче средствами k8s, чем встраивать в само приложение.
    8. Vert.x асихронные колбэки сложно/невозможно мониторить многими популярными системами мониторинга. Например я был к команде тех — кто потребовал от appdynamics реализовать поддержку Vert.x в их продукте года 3 назад, до этого- appdynamics java client ничего почти не видел в vert.x кластере.
    9. C10k problem — всплывает если пишешь highload на vert.x без предварительной подготовки.

    10. Vert.x поддерживат множество языков программирования. Например JavaScript. Но писать Vert.x приложение на EcmaScript 5 (на тот момент nashorn engine -поддерживал только 5 версию)- это очень малоприятное занятие- не говоря уже о том что документации и примеров- примерно «0» (не спрашивайте зачем мне это понадобилось- было такое требование)

    Но хватит о проблемах. Vert.x действительно отличный фреймворк. Я большой фанат этой штуки и уже сделал множество решений на Vert.x.
    Если надо сделать быстрое, малотребовательное, достаточно низкоуровневое (если это слово можно применить к java) — приложение— Vert.x это ваш выбор.

  • Поделитесь опытом построения микросервисных систем

    А чем конкретно занимаются сервисы оркестрации?

    Это набор сервисов — которые знают свою зону ответственности и могут направлять данные на обработку сервисам о которых они знают. (serviceorientation.com/...​soaglossary/orchestration) Допустим есть входное сообщение, self describing json- сервис оркестрации читает сообщение и если понял какую либо инструкцию- перенаправляет сообщение соответствующим сервисам на исполнение в паралель (топология- звезда), собирает результаты выполнения и отправляет обратно клиенту. В случае если сообщение не понято/частично не понято- сервисом оркестрации — перенаправляется следующему в цепочке сервису оркестрации( en.wikipedia.org/wiki/Pipeline_(software ) . Таким способом- я строю легко расширяемую систему- без необходимости править существующие микросервисы- при добавлении новой фичи. Получается сеть из сервисов оркестрации о зонами ответственности (сервисы исполнения).

    Kubernetes это оно?

    Кубернетес — это слой оркестрации инфраструктуры. Я же говорю о сервисах оркестрации приложения работающего поверх кубернетес.

    разделение на сервисы бизнес логики и сервисы доступа к данным, в чем фишка?

    Это фишка отлита кровью и и нервами моего опыта- когда закачик приходит говорит- ко мне вчера приходили сейлзы оракла и сказали что сделают хорошую скидку на оракл экзадата- при условии подписания контракта на 5 лет с оплатой upfront. и заказчик соглашается на это. И это при наличии MS SQL, MySQL, Kafka, Influxdb, Informix etc.
    В итоге надо работать с целым зоопарком источников данных- и поэтому vendor specific CRUD operations реализованы в виде отдельных сервисов.- ну и обращаться к ним могут множество других сервисов при необходимости.

    Если сервис реализует бизнес логику, разве у него не должно быть доступа

    Доступ к данным остаётся- только обращаться к данным сервис будет путем вызова соответствующего CRUD микросервиса — так проще поддержку осуществлять. Ну и секьюирити никто не отменял- незачем сервису бизнеслогики ходить в consul vault за строкой подключения с базе данных.

    Підтримав: anonymous
  • Поделитесь опытом построения микросервисных систем

    Вся прелесть распределенных систем состоит в том- что при их разработке- изначально закладывается опредленных уровень прочности, т.к. Распределенная система будет фейлить- и это должно быть учтено дизайном. Trust no one.
    Каждый сервис желательно включить поддержку Retry,Circuit Breakers, heartbeat etc

  • Поделитесь опытом построения микросервисных систем

    И сколько версий одновременно поддерживаете?

    На данный момент- самай глубина истории — 4- так как есть внешние клиенты- ну с ооооочень медленным циклом разработки- новую версию выкатывают раз в 3 месяца и большой болью. Для них на проде держу 1 версия сервиса интеграции с их подделкой- тогда как как на остальных environment-ах уже поддерживаю их новую спецификацию т.к. я использую URI versioning — то мне не проблема деплоить один и тот же код на все environment-ы. Каждая версия работает независимо.

    Есть процесс отказа от устаревших версий API

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

    Тесты пишете на конкретный кусок функциональности(сервис) или есть тесты покрывающие всю систему целиком?

    Пишу три вида тестов
    1. Юнит тесты — каждого публичного метода в каждом классе.
    2. Функциональные тесты — тестится связка одно или нескольких сервисов одновременно — тест фич другими словами
    3. Бэк тесты — т.к. я пишу AI систему- то после добавления каждой новой фичи — необходимо проверить как это отразилось на рассчетах проведенных в прошлом (обратная совместимость на уровне данных)

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

    Допустим у меня есть сервис с товарами, есть сервис с клиентами и сервис с заказами.

    Я не знаю всей подноготной, но думаю здесь тоже можно применить принцип декомпозиции.
    Думаю моожно сделать примерно так:
    1. Разбиваешь задачи на независимые сущности
    2. Создаешь сервисы оркестрации взаимодействия между всеми сущностями
    3. Создаешь сервисы доступа к данным
    4. Создаешь сервисы безопасности
    5. Создаешь сервисы взаимодествия с third party systems (if any)
    5. Создаешь сервисы фасады для общения с клиентами (web, sockets, udp/ tcp, etc)

    Цепочка взаимодействия может выглядеть примерно так
    клиент ->(your prefered protocol) -> Load Balancer -> сервисы фасада ->(raw message)-> сервисы безопасности -> сервисы оркестрации -> (выбор что надо делать в паралель/последовательно) сервисы бизнес логики -> сервисы доступа к данным/сервисы взаимодествия с third party systems

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

    Внутри кластера (виртуализации) — сетевой обмен это небольшая проблема- т.к. организовано все это внутри кластера (3 и больше хостов организуют кластер, которые обычно соединены между собой high speed fiber channel)
    После того, как сообщения прошло проверку безопасности- оно дублируется всем сервисам в исходном виде — на выходе сервисы оркестрации собируют результаты со всех сервисов что уложились в SLA- и формируют ответ клиенту ( с заглушками если кто то опоздашка)

    Підтримав: anonymous
  • Spring MVC. С чего начать?

    начни с vert.x

    Підтримали: stufsdf, anonymus ps
  • Как вы здороваетесь в опен-спейсе? крик

    Надо разделять рабочие отношения и нерабочие.
    На работе здороваюсь только если есть eye contact. Но в большинстве случаев это только экспаты.
    Ну кухне все держатся обособленными группами.
    Доходит до того- что если сменил проект и команду- то с предыдущей командой больше не общаешься- работа.
    Как пишут во всяких книгах по развитию личности0 никогда не ешь в одиночестве. Обычно приглашаю кого- либо из коллег на ланч/кофе. Это лучший способ узнать внутренную кукню компании.
    Ну и еще важны внерабочие ивенты.

    Підтримали: Ivan Pruchai, Oksana Chuiko
  • Чего вам не хватает на форуме?

    Комментарии. Улучшить работу с комментами. Например популярная тема с 500+ коментов очень сильно нагружает систему. К примеру постраничный вывод сделать. rsdn- отлично решили эту проблему. Вообщем постраничный вывод + ajax подгрузка должны улучшить ситуацию

  • Жизнь мобильного (Андроид) разработчика

    Да, есть стандартный подход.
    1. Создается дизайн приложение (картинки, оформление и тд)
    2. Создается каркас приложения — желательно резиновый.
    3. Собирается сборка только для телефонов и отдельно сборка для HD экранов. Это делается для того чтобы уменьшить общий вес apk. Иногда делают больше форков под разные типы устройств.
    4. В случае с играми часто делают форки под разные железки. Например на Tegra устройствах свой конвеер обработки граф. примитивов и доступны уникальные для tegra шейдеры. Сейчас еще и Intel выпускают свой граф. процессор для андроид устройств.
    В этом и состоит основные трудности разработки под андроид. Для больших проектов, чтобы сделать качественное приложение приходится держать в || много форков.
    Это мне напоминает детские болезни становления платформы как PC в 90-х тоже были проблемы совместимости ATI и NVidia железок, а игрушки затачивались под что то одно обычно.
    Ничего, это временно- скоро устаканится.
    Андроид отличная платформа для разработки, уж поверьте.
    К тому же Nasa рассматривает эту платформу как основу для своих мобильных устройств, как полностью открытую. Что в свою очередь приведет к росту рынка гос заказов на платформе андроид.

    Підтримали: Roman Novikov, bad touch
  • Жизнь мобильного (Андроид) разработчика

    Java +OpenGL ES

    Підтримав: bad touch
  • Жизнь мобильного (Андроид) разработчика

    Меня сложно назвать Андроид разработчиком, пару лет назад писал игрушку под андроид. Что могу сказать:
    1. На джаве писать очень легко ( у меня C#/С основные)
    2. Отлаживаться лучше на девайсе — эмулятор ужасно медленно работает.
    3. Проблема фрагментации замечена не была. Если пользоваться резиновой версткой для UI и писать качественный код- то все будет -Ок, почти везде. Я проверял свое приложение на 4 разных девайсах- везде все работало отлично, и на разных версиях андроида.
    4. Разрабатывать под Андроид можно и нужно- еще не так много приложений сделано как под яблофон.
    5. Делал для себя- pet project, поэтому пресовал меня только лишь я, сам.
    6. Дизайн, кодинг, делал сам- тестировать помогали жена, друзья.
    7. Фриланс под андроид на "дядю"- не знаю, из того что я видел мало прибыльно. Но это то что видел я на одесках.
    8. Продавать по честному приложения с Украины низззя. Так что прийдется делать либо бесплатное с рекламой/внутренними покупками, либо искать обходные пути.
    9. Пользователи у андроида- откровенно говоря- хрюнделя- очень часто сливают рейтинг приложению т.к. не разобрались в нем.
    10. Ну и сама платформа мне очень нравится.
    Вот ссылка на раннюю версию моей игрушки

  • Инновационный (технологический) прорыв!

    Агрономы, Баролгины, Эферолганы и их брат меньший- Иммодиум

  • Инновационный (технологический) прорыв!

    Плёвое дело.
    Вот примерный список мелочей которые надо решить для построения робота собирающего колорадского жука:
    1. Выбор/разработка экономически выгодных комплектующих
    2. Решение проблемы энергопотребления(батареи, двигатели внутреннего сгорания, провод к резетке)
    3. Низкоуровневая разработка драйверов устройств (управление манипуляторами, перемещение в пространстве и т.д.)
    4. Эффективная система распознавания образов, поиск жуков под листьями, на стебле.(Т.е. одновременно распознавание внешнего вида растения, умение отодвинуть лист/стебель не повредив его, поиск жуков по всему растению)

    5. Коробачка для сбора и хранения жуков.

    Да, всё перечисленное вполне реально, можно кстати для начала сделать заказ в Boston Dynamics, они то уже собаку съели на этих роботах.

  • «Подтверджденные аккаунты» за пределами форума

    Это хорошая новость.

    На днях хотел создать топик-вопрос на форуме но оказалось не все так просто- т.к. оказыватся «нэможно» — подтверди аккаунт- отправь смс на короткий новомер. Вообщем еще раз- отлична новость

  • Всем спасибо за внимание

    Суть данного флейма:

    Вcе вокруг п***сы- один я Д’артаньян.

  • Всем спасибо за внимание

    Вот тебе уважаемый несколько причин для дикой ненависти к «неньке»
    1. Хамство в обществе как основа общения. Заходим в супермаркет/магазин- на кассе нагрубят, нахмурятся, влезут без очереди, не улыбаются и тд.
    2. В автобусе обязательно набьется куча народа и будут топтаться друг другу по ногам.
    3. Практически никто никогда не извенится если наступил на ногу/толкнул и тд В лучшем случае хмуро посмотрят.
    4. «Наливайки» придорожные и соответствующий контингент блюющий «кудапопало»
    5. Oбoссаные подъезды случаются даже в «Элитных Домах Киева» (это наверно из завести- что подъезд слишком чистый)
    6 Мусор- он везде. Бросить окурок в урну- это высшая математика- надо просто всё изгадить =)
    7. Воровство- Блин народ в Люксофте вроде и зарабатывает неплохо- зачем чай в пакетиках и сахар пачками с кухни растягивать по карманам????
    8. Советы- каждый считает своим долгом сказать как и что делать.
    9. Раздолбайство- много раз наблюдал. Надор отремонтировать дорогу- ок- дождемся дождей и заморозков- и положим новый асфальт. И уже весной его надо будет заново переделывать.
    10. «Попрашайки» -Есть у тебя вполне успешный оффлайн бизнес- обязательно прийдут с санэпидемки/пожарники/милиция/налоговая- и все будут клянчить на «день рождения шефа» (это из личного опыта)
    11. Полный беспредел на дорогах — без коментариев =)
    12. Завистливость нашего брата- во многом проявляется.

    13. В качестве оправдания всего этого обычно приводят еще худшие по данным пунктам страны. Но равнятся то надо на лучших.

    Ну что товарищЪ- достаточно?

  • Работа в Ирландии

    Вот как интересно выходит, только что пришло приглашение пообщаться по поводу работы в Ирландии. Захожу на ДОУ, и здесь уже есть подобная тема.

    Случайности не случайны.

  • У кого какая ОСь на телефоне(мобильном устройстве)?

    win mobile 6.1 on phone

    & android 4.hz on galaxy tab 2

  • Запрошення відвідати вебінар Як влаштуватись Junior Java Developer в аутсорсну компанію за 1 місяць

    СРОЧНО!!!
    Предлагаю уникальную возможность купить диск c обучающими системами «как стать миллионером».

    Цена со скидкой $99

    ---З.Ы.

    TrollFace

← Сtrl 123456...9 Ctrl →