• Релокейт і життя в Чехії — AMA (Ask Me Anything)

    А полячки красивей чешек и словачек вместе взятых :)

  • Релокейт і життя в Чехії — AMA (Ask Me Anything)

    Был почти пол-года в Люксембурге — тоже один из городов в котором расположены офисы EC.
    Но летать каждые две недели на выходные домой малоприятное удовольствие.
    Местные коллеги жаловались на заоблачную цену аренды жилья.
    Некоторые ездили каждый день вскладчину на авто из соседней Бельгии.
    Один вообще жил в какой-то деревухе, куда в свою очередь наезжал переодически из Франции.
    Так что с арендой жилья там просто жопа.
    К гадалке не ходи, но в в Брюсселе все тоже самое только в квадрате.

  • Релокейт і життя в Чехії — AMA (Ask Me Anything)

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

  • Релокейт і життя в Чехії — AMA (Ask Me Anything)

    Мои пять копеек.
    — 160 тыс кронн в мес на HPP — это маловероятно, хотя возможно сейчас что-то изменилось.
    На контракт реально, но для того чтобы вас взяли на контракт надо иметь хотя бы ПМЖ.

    — Вы уверены что именно Microsoft лучший вариант в плане зарплат? Я слышал что лучший вариант это Barclays и Novartis.

  • Інструкція по вакцинації у Києві (оновлено 21.07.2021)

    Вспомни СССР, если застал — экспортные варианты товаров отличные, а своим — говна на лопате. Соответственно на Союзе зарабатывал весь мир, получая сырьё и некоторые товары за бесценок. В том числе вакцины.

    «Если человек умер, то это надолго, а если он идиот то это навсегда©»

  • Інструкція по вакцинації у Києві (оновлено 21.07.2021)

    Запрещено по банальными причинам конкуренции. Как вам например запрещено общаться в магазинах на русском языке.

    Уважаемый вы — непроходимый идиот, представитель генерации «Зебланов».

    Причина запрета Спутника V в Европе проста.
    1. РФ так и не предоставила полную документацию для прохождения сертификации, и под разными предлогами оттягивала этот процесс, попутно пытаясь протолкнуть без сертификации, в отдельно взятых странах где на текущий момент у власти популисты.

    2. «позитивные результаты» которые были опубликованы в уважаемом журнале «The Lancet» были опубликованы со слов РФ медиков, и поздней не были потдверждены, а мы ведь знаем, что в стране где «фэйк — норма жизни» ничего путнего не может появиться.

    3. Бразильцы обнаружили образцах вакцины живой аденовирус, который должен быть деактивирован. (хреновое качество). Это снижает эффективность и без того никакой вакцины.
    каждая очередная «варка», отличается от предыдущей, что непосредственно указывает на отсутствие контроля качества со стороны производителя.

    4. С самого начала было понятно, что сертифицированных вакцин поставляемых на внутренний рынок ЕU будет более чем достаточно для закрытия своих потребностей и основные сложности часто связаны с эффективной организацией процесса массовой вакцинации.

    Пару примеров, когда страной управляют «Зебланы».

    Словакия:
    популист и бывший премьер Игорь Матович «тайно» подписал договор о поставке Спутника без согласования с кем-либо. В итоге лишился своего поста. Чуть позже на публику попало содержание контракта с РФ из которого следует:
    — вся отвественность за побочные эффекты ложится на словацкую сторону
    — содержание контракта нельзя публиковать иначе штрафные санкции.
    — старый добрый подход «бери или плати», то есть в контракте упомянута поставка 2 млн. доз за 16млн Евро.
    — разрешения от местного министерства здравоохранения на использование вакцины так и не было получено.
    — Словаки получили первые 200тыс доз, при этом 80% документации на нее отсутствовало в результате вакцина пылица на складе. Срок годности заканчивается в июле.
    — востребованость, то есть кол-во человек которые изъявили желание вакцинироваться именно Спутником аж 7,5 тыс человек.

    И вишенка на торте, ну как обычно у популистов бывает:
    Сам бывший премьер Игорь Матович наотрез отказался вакцинироваться Спутником, и был вакцинирован Pfizer-ом.

    Чехия.
    Аналогично повел себя полоумный президент Чехии Милош Земан.
    Во всю торбил за Спутник, а сам и свое окружение вакцинировал Pfizer-ом.
    В Чехии чуть-чуть не повторилась ситуация аналогичная Словакии.
    Министр внутренних дел уж собирался вылетать в Москву, но тут всплыла инфа о том что 7лет назад россияне с помощью своих агентов, взорвали военный склад в Вербетицах, в результате которого погибли мирные граждане и процесс застопорился.

  • О работе в стартапе, неспешной медицине и высоких налогах. История программиста, который вернулся в Украину из Ирландии

    В Испании, Португалии и Италии цена на одноразовый билет в районе 1,10 — 1,25 Евро. 2Евро в том случае если вы берете билет непосредственно у водителя при входе.

    Поддержал: Oleg Antoshkiv
  • DevOps дайджест #34: AWS re:Invent, Kubernetes deprecating Docker, Prometheus vs VictoriaMetrics

    разных взглядов на PromQL

    Вот об этом я не слышал, но я и неособо слежу за системами мониторинга.
    Спасибо.

  • DevOps дайджест #34: AWS re:Invent, Kubernetes deprecating Docker, Prometheus vs VictoriaMetrics

    Спасибо.
    Частично согласен.

    если мониторинг начнёт генерить много данных и принимающая сторона «захлебнётся»,

    а) Это вряд ли, потому что объем данных в BI обычно сильно больше.
    б) всегда можно организовать на уровне сервиса отдельный ресурс пул для мониторинговых данных.

    независимое масштабирование этих подсистем;

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

  • DevOps дайджест #34: AWS re:Invent, Kubernetes deprecating Docker, Prometheus vs VictoriaMetrics

    Объясните, если кто знает по теме VictoriaMetrics vs Prometheus.
    VictoriaMetrics позиционируется как timseriesDB.
    Если узкое место систем мониторинга именно в timseriesDB, то почему не взять что-то более или менее пригодное не только для мониторинга.
    Например взять тот же Druid, сделать к нему коннектор и использовать его не только для хранения данных мониторинга но и BI аналитики.
    Немогу понять зачем этот огород с очередным узкоспециализированными engine-ом? Это не камень в огород VictoriaMetrics, если что.
    Я упускаю какой-то нюанс?

  • Почему из офиса работать лучше и эффективнее

    Сюда же:
    — летом борьба за пульт от кондиционера, потом что одним холодно при +26, а другим жарко +20. — борьба за пульт управления жалюзями, потому что одним восходящее солнце слепит, а в другом углу типа «темно».
    — гул «утреннего трепа» , когда пришедшие в офис сотрудники обмениваются новостями вчерашнего дня.

  • Без YouTube, соцмереж і новин навколо. Як і навіщо зменшувати інформаційний шум

    Еще замечания будут? Или это все на что вас хватило?

  • Без YouTube, соцмереж і новин навколо. Як і навіщо зменшувати інформаційний шум

    По-моему статью было бы точней озаглавить «как я устала от карантина» :)

    Автор не видит разницы между шумом и «информационным шумом».
    Первый — это звуковые волны, а второй — это информация.
    Если у вас проблема с шумом, то решается она сильно проще, путем изолирования источников шума и неважно отключите вы нотификацию в месенджере или вставите себе в уши беруши, суть всегда одна и таже «убрать лишние источники шума(раздражители) не позволяющиеся вам сосредоточится».
    К «информационному шуму» это не имеет отношения, поскольку речь идет об фильтрации информационного потока на основании которого в последствии принимаются те или иные решения.

    Цель же борьбы с «информационным шумом» по-моему является фильтрация недостоверных, неактуальных и низкокачественных источников информации. Это как если бы вам удалось окружить себя людьми, с интеллектом на голову выше вас и удержаться в их окружении, то как следствие через какое-то время вы тоже немного поумнеете. :)

    Проблема «информационному шума» так же решается достаточно просто, путем
    ранжирования информационных потоков по уровню качества, достоверности, информативности, полезности, правдивости и актуальности.

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

    Пример 2.
    На FB у меня есть знакомые который регулярно распространяют инфу с Fake-news сайтов и иных «информационных помоек», не утруждая себя элементарной проверкой источников информации. У меня для этого есть простое правило.
    Указывать на ошибки три раза, после чего такой «friend» неявно помечается приоритетом «несерьезный» и инфа от него более не воспринимается и в последствии просто фильтруется. Это все равно как не слушать малолетнего ребенка, высказывающегося о проблемах высокого порядка. Старый добрый принцип «солгавший единожды солжет дважды».

    Пример 3.
    Источники информации.
    Чем чаше я ловлю источник на подтасовке, передергиваниях и т.д. и т.п. тем ниже его рейтинг, и тем дальше он отодвигается «в сад», пока полностью не исчезнет с моего горизонта.

    Пример 4.
    Реклама. Мы все прекрасно понимаем, что реклама не относится к правдивым источникам и требует тщательной проверки на правдоподобность а это требует времени, следовательно может быть легко отфильтрована. Например, я рекламу воспринимаю в виде цветных картинок ничего не значащих. Реклама — это аналог продавцов расхаживающих по домам и пытающихся «впарить» ненужный товар застигнутым в расплох жильцам, оказывая при этом психологическое давление, чтобы не дать потенциальным покупателям сосредоточиться минимизируя время на размышление и принятие решения. Отсюда следует простой вывод: «никогда ничего не покупать с рук», и если следовать этому правилу, то тогда вы сами становитесь «хозяевом своего времени», иными словами занимаетесь поиском того что вам нужно и тогда когда вам это нужно.
    Результат: «вся реклама пропускается мимо ушей автоматом» — удивительная способность мозга, кстати.

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

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

    Наступним кроком став спортзал, і найсмішніше тут те, що я купила абонемент 11 березня, а 12-го почався карантин. Ті, хто мене добре знає, в курсі, що я трохи на «ви» зі спортом після того, як закинула 10 років тому фігурне катання.

    Извините, но я не верю в искренность вашего желания, тем более с учетом 10 летнего спортивного опыта, потому что приоритеты «на сидят».
    Простой лайф-хак:
    наберите в YouToub-e «resistance band workout». Это простой способ как создать себе физическую нагрузку в домашних условиях за мало денег.

    Поддержал: Pasha Radiuk
  • «Якщо не у першій двадцятці співробітників, то на опціонах не заробиш». Як розробники опціони (не) отримували

    Работал когда-то я в одной компании, в которой всем сотрудникам выдали опционы на определенную фиксированну сумму, и на такую же сумму позволили приобрести за собственные деньги. Если увольняешься, то автоматически компания выкупала опционы обратно.
    Перед этим правда компания года 3 не платила годовых бонусов, но в итоге компанию продали, и по условиям продажи новые владельцы выкупали все опционы.
    В этот момент я пожалел, что не приобрел дополнительно предлагавшихся опционов за свои.
    Даже без этого сумма получилась очень неплохая и с полученных денег платился только подоходный налог без отчислений на медстрахование и социалку, как это бывает с бонусами.

    Вывод:
    «Главное, оказаться в нужном месте в нужное время, а вот насколько ты крут совершено неважно» :)

    Поддержали: Dmytro Skrypka, Artem Kurakin
  • Мой опыт сертификации — экзамен Oracle 1Z0-071

    Как бывший Oracle DBA могу порекомендовать вам не тратить попусту свои деньги.
    Oracle cо своими решениями уже давно в прошлом(имеется ввиду уровнь решений предлагаемых компанией), так что смысла сертифицироваться 0.
    Потому что:
    — Дорогие решения сегодня нахер никому не нужны, как и люди имеющие сертификат по ним.
    — Oracle «впаривает» вам в нагрузку софт, который не нужен и никогда не пригодится.
    — существует просто «воз и маленькая тележка» решений которые решают аналогичную проблему за меньшие деньги.

    Рекомендация:
    — Лучше потратить эти деньги на изучение новых технологий на том же Udemy.
    — Если нет желания учиться, то лучше пропить. :)

  • .NET дайджест #32: приложения на Blazor, Azure побеждает AWS, gRPC в .NET, ReSharper и Rider обновились

    www.theverge.com/...​ct-jedi-10-billion-paused
    A judge has issued a temporary injunction against the Pentagon’s Joint Enterprise Defense Infrastructure (JEDI) cloud contract, preventing the contract from moving forward until a lawsuit from Amazon is resolved

    Там вообще изначально Амазон выигрывал, но потом туда влез Трам, у которого проблемы с Jeff Bezos-ом, что в итоге с подачи Ларри Элисона привело к тому, что контракт выиграл MS, хотя ему изначально вообще ничего не светило.

  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    Софта подпадающего под описание timeseries DB достаточно. Проблема в том, что не всякий timeseries DB годится для аналитики, а вот упомянутая тройка годится.

    TSDB

    которому нужен HBase, который в свою очередь хочет Hadoop инфраструктуру, что не всех приводит в восторг. :)
    Про InfluxDВ ничего не скажу ибо не знаю, и пока у нас нет никаких аргументов для того чтобы отказываться от Druid-a в пользу чего-то еще.

    У Druid-a есть свой Кафковский коннектор, который легко подключается в топику и можно сразу нарезать и анализировать потоковые данные, по сути без программинга.

  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    Еще немного по Druid-у и я пойду пожалуй.
    1. У него существует два API доступа к даным:
    — JSON-запросы — самый быстрый способ доступа к данным на данный момент
    — SQL-сервис на базе Avatica. Встречается инфа что в будущем разработчики планируют постепенно перейти на него в качестве основного, но пока это не так.
    2. В Druid-e схема данных определяется дискриптором ingestion task-и, таким образом у него легко возможна ситуация при которой сегменты разных временных интервалов могут иметь разнуют структуру данных.
    3. В Druid-e нет ничего похожено на delete/insert/update. Данные в Druid-e нельзя изменить через SQL, только через таски. Сегмент данных не меняется.
    4. Сегмент данных(интервала) можно только перезалить. В зависимости от типа источника.
    Если источник файл формата CSV/TSV/JSON (c доп. плагинами поддерживается AVRO, Parquet и ORC), то есть возможность делать append или rebuild. В случае потоковых данных только append.
    5. В Druid-e на текущий момент отсутствуют JOIN-ы. Это непривычно конечно, и мне трудно сказать является это недостатком или фитчей ибо с одной стороны это удобно, с другой это 100% проблематичное место оказывающее влияние на производительность.
    6. Cамое хлипкое место Druid-a, как и в Hadoop-e — это метакаталог в качестве которого используется классическая СУБД MySQL или PostgreSQL или что-то еще. Все остальные сервисы могут дублироваться и по мере разрастания кластера организовываться в пулы.

    Из личных впечатлений.
    Мне всегда было интересно познакомиться с NoSQL решением, решающим проблему интеративного анализа данных, при этом использующее для хранения данных медленный Deep Storage типа AWS S3 и его альтренатив.
    Druid — отличный пример, того как это может быть реализовано.

  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    Я практически на 100% уверен, что если я попрошу вас предоставить сравнительную таблицу «этих самых соотношений» у вас ее вдруг не окажется, не так ли? :)

    Когда не понимаешь, как оно работает, всегда переводи тему на Enterprise bullshit. :)

    Apache Druid — полностью опенсорсный Java-base проект, в котором нет ни единного проприентарного компонента.
    Без проблем поднимается в докере. Много сервисов с которыми надо разбираться? Так с любым софтом надо разбираться. У меня например на десктопе легко поднимается докеровский env для отладки pipeline-ов, состоящий из сервисов Кафк-и, Druid-a, Vertica-и и т.д cовместно работающих.
    Для желающих есть компания imply.io которая осуществляет его коммерческую поддержку продукта.
    Если вас напрягло слово Hadoop, то оно было упомянуто в качестве примера дополнительной сферы применения Druid-а и только.

  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    По соотношению количества фичей к стоимости эксплуатации альтернатив я не знаю.

    Не надо грязи© :)

    Прямые конкуренты Apache Druid, Apache Pinot и еще много менее известных проектов.
    Это класс продуктов под названием timeseriesDB. Если это знать, то становится сильно проще искать альтернативы и сравнивать их.
    Учитывая системные риски, связанные со страной происхождения ClickHouse-a, нет смысла с ним связываться. Кроме того, на момент рассмотрения у него были ограничения которых не было у Druid-a.

    Далее о Druid-e.

    The data we had in MongoDB was migrated. This data stored in MongoDB was using approximately 60GB of disk space, and when indexed inside Druid, the same data represented only 600MB. Yep. 100x less storage!

    Источник: towardsdatascience.com/...​ion-to-druid-4bf285b92b5a
    У Druid-a это работает так.
    Во время ingestion task в описании которой содержится dimensions и measurements и глубина детализации ( segment Granularity) согласно этому описанию нарезаются сегменты данных, сжатый колоночный формат с бинарными индексами.
    Сервис который этим занимается в Druid-e называется MiddleManager или индексатор.
    Сегменты данных укладываются в Deep Storage ( NFS, HDFS, Amazon S3, Google Cloud, Apache Cassandra и т.д).
    Суть в том, что скорость Deep Storage-a не оказывает никакого влияния на производительность пользовательских запросов, поскольку при старте сегменты данных поднимаются с Deep Storage на сторону Historical сервисов где разархивируются на в локальной FS и постепенно поднимаются в кэш файловой системы хоста на котороий запущен сервис. То есть фактически все входящие запросы попадают на данные который находятся в памяти, отсюда миллисекундная скорость ответов на запросы.

    Основная сфера применения Druid-e это конечно же чтение и аггрегация потоковых данных, через коннектор из Kafka-и и подобных источников данных. Аггрегация происходит почти в online. Как только фрагмент данных, считанный из топика Кафки проиндексирован индексатором, он сразу же становится становится доступным для пользовательских запросов, еще до того как оно он будет уложен в Deep Storage и потом поднят Historical сервисом в кэш, просто пока это не случилось за эти сегменты данных отвечает MiddleManager. То есть при работе с потоковыми данными пользовательский запрос посылается на Broker сервис, который собирает сегменты удовлетворяющие условиям фильтрации пользовательского запроса из разных сервисов ( Historical , MiddleManager)

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

    Хочу особо подчеркнуть, что подобный софт — сильно далек от классической СУБД и предназначен для узкого круга задач, с которыми он отлично справляется.

    P.S.
    Хочу так же обратить внимание на еще один интересный момент. Apache Druid может использоваться как самостоятельный сервис, но так же находит применение в Hadoop стэке от бывшего HortonWorks в связке с Hive + LLAP + Druid, что делает пригодным Hadoop для интерактивной аналитики. Оптимизатор (я его так называю) TEZ генерирует DAG из пользовательского запроса составляющими которого могут быть как сегменты данных в Orc на HDFS-e , так и хэндлеры Druida. В последних версиях к ним добавились хэндлер JDBC датасорса , хэндлер топика Кафики.

    Прошу прощения за много слов.

    Поддержали: Vlad Voloshyn, Dmitriy Onykyyenko
← Сtrl 123456...13 Ctrl →