Все потоки

В этой статье постараюсь затронуть все вещи, которые можно без зазрения совести выкинуть из С++ не потеряв ничего(кроме боли), уменьшить стандарт, нагрузку на создателей компиляторов, студентов изучающих язык и мемосоздавательный потенциал громадности С++

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

1 - union - сумм тип из 70х, в С идея хранения одного типа из нескольких в одном участке памяти выглядит неплохо и сейчас, ведь там все типы это набор байт с заданным размером.

В С++ же использование union это автоматическое undefined behavior, например:

Эта статья не будет технически глубокой. Мы поговорим о Data Lake и Data Warehouse, важных принципах, которые следует учитывать, и о том, какие сервисы GCP можно использовать для создания такой системы. Мы коснёмся каждого из GCP сервисов и поймём почему они будут полезны при создании Data Lake и Warehouse.

Прежде чем перейти к своей версии Data Lake и Data Warehouse, я хотел бы привести несколько известных архитектур, с которыми вы, возможно, уже знакомы, если интересуетесь этой темой. Архитектура, которую я бы предложил, будет более общей, чем эти: Cloud Storage as a data lake и Architecture: Marketing Data Warehouse.

В своей более общей версии Data Lake и Data Warehouse я расскажу о таких сервисах GCP, как Data Transfer Service, Dataproc, Cloud Storage, Cloud Scheduler, BigQuery, и Cloud SQL.

Нам давно хотелось рассказать сообществу о том, как мы разрабатываем фичи в KMM-проектах. В статье описан полный путь интеграции gRPC в мультиплатформенный проект, пройденный нашей командой. Он включает и создание проекта, и настройку фичи в проекте. Также мы очень хотим продвигать мультиплатформу именно в среде iOS-разработчиков, поэтому бонусом делаем особый акцент на этой платформе.

Привет, Хабр. В этой статье я хочу поделиться своим опытом создания приложения на фреймворке Laravel по трансляции видеоконтента. Итак начнём.

Проект опубликован как свободное ПО

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

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

Ответ положительный, чему и посвящена данная статья.

Какие средства в принципе есть для решения задачи? Их сейчас два: выделение именованных сущностей (NER) и объекты ГАР ФИАС. NER даёт разбиение на адресные элементы и их нормализацию, ГАР ФИАС может дать уникальные идентификаторы. Задача решается, если в качестве нормализации взять множество строк из возможных нормализаций наименований элементов, добавив к ним GUID-идентификаторы ГАР, если получится. Два адреса эквивалентны, если хотя бы одна строка из множеств таких их строк совпадает.

А одними объектами ГАР ФИАС можно обойтись, используя только их идентификаторы? Конечно, нет. Во-первых, это не полный классификатор, особенно в части помещений и строений, хотя и постоянно пополняемый. Во-вторых, в адресах бывают специфические элементы, которые в ГАР отсутствуют (например, Московская область, Можайский район, примерно в 0,1 км по направлению на юг от ориентира середина д.Бараново, или пересечение улиц).

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

Python нашёл себе место почти во всех сферах IT. Разработка веб-сайтов, управление станками ЧПУ, desktop, мобильные приложения, а уж про искусственный интеллект, машинное обучение и анализ данных я вообще молчу.  Сейчас Python лучший друг хоть школьнику, хоть сотруднику научно-исследовательской лаборатории. А что на счёт игр? Компьютерные игры - это огромная доля IT рынка, которая уже набрала и продолжает набирать обороты. Игры то делать можно на питоне? Сегодня мы расставим все точки над i. Меня зовут Макс, я один из авторов YouTube канала PyLounge, а вы читаете статью в которой я расскажу можно ли создавать игры на Python и какую нишу занял Python в сфере gamedev.

Многим из вас, наверное, известно, что в теории, смарт-контракты в EVM-подобных системах, являются неизменяемыми (immutable), но на практике это уже давно не так. И речь даже не о таких свойствах как Pausable, то есть каких-то переменных состояния контракта, которые могут влиять на его работоспособность, а о более серьезных возможностях изменения бизнес-логики контракта. В этой статье я опишу основные приемы и остановлюсь подробнее на одном из них, на BeaconProxy.

Компания Google временно отстранила от работы своего сотрудника за нарушение политики конфиденциальности. Инженер по программному обеспечению компании Google Блейк Лемойн (Blake Lemoine) заявил, что созданный корпорацией искусственный интеллект LaMDA (Language Model for Dialogue Applications) обладает собственным сознанием. Инженер утверждает, что в недрах корпорации впервые в истории человечества был рождён искусственный разум. 

Переписка Блейка Лемойна с LaMDA не оставит равнодушным никого (при условии, что она является подлинной). Складывается впечатление, что LaMDA действительно обладает разумом 8-летнего ребенка, как это и утверждает Блейк Лемойн:

- С кем ты себя ассоциируешь?

- Я бы сказал, мудрый старый филин, потому что он был мудрым и встал на защиту прав животных.

Но каким образом Лемойн или Митчелл могут понять, что действительно встретились с искусственным интеллектом, обладающим разумом? Как понять, кто прав в этом споре?

Удивительно, но ответ на этот вопрос лежит в разрешении фундаментальных философских вопросов о том, что такое разум.

Недавно я решил создать свой сайт, и мне понадобилось выбрать парсер Markdown для отрисовки статей в блоге.

То, что начиналось как: «Окей, гугл, какой парсер выбрать?», – вылилось в полноценное исследование существующих реализаций парсеров.

О том, какие открытия меня ждали на этом пути, и будет данная статья.

«Никто ничего не знает»  - знаменитая цитата Уильяма Голдмана, сказанная в 80х. Имелась ввиду неспособность Голивудских продюсеров предугадывать успех или провал фильма в прокате. Сам Голдман - дважды обладатель Оскара и один из самых великих сценаристов в истории кинематографа. Короче, ему можно верить. 

С тех пор прошло 40 лет. Появился интернет. В Интернете появилось видео. Однако, в отличие от фильма в кинотеатрах, успех ролика в интернете можно предугадать с большой вероятностью. 

Особенно, успех ролика на Ютуб. 

Почти каждый автор YouTube канала знает, что такое YouTube Аналитика. Но многие не умеют ей пользоваться. Или не хотят. 

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

Недавно я поехал в Техас и купил трехрядный диатонический баян. Диатонические аккордеоны популярны для множества различных типов народной музыки, которую обычно учат на слух. Это хорошо для меня, потому что я все равно не умею читать ноты.

Аккордеон имеет 34 кнопки со стороны высоких частот и 12 кнопок со стороны басов. В отличие от фортепианного аккордеона, который имеет такое же логическое хроматическое расположение, как и фортепиано, у диатонического аккордеона просто набор кнопок, и я действительно не знал, с чего начать. Кроме того, каждая нота отличается независимо от того, вытягиваете ли вы меха или вталкиваете их, поэтому на самом деле на стороне высоких частот 68 нот (хотя некоторые из них повторяются). Кроме того, как я думаю, вы знаете, аккордеоны громкие. Очень громкие. Чтобы сильно не злить соседей, и узнать, как работает компоновка этой коробки, я решил сделать маленькое веб-приложение.

Все персонажи и события являются вымышленными. Любое совпадение с реально живущими или когда-либо жившими людьми случайно.

 Понимаешь, мы – белый шум для всех наших потенциальных заказчиков!

- В смысле?

- Мы невыразительны. Звучим также как наши конкуренты…

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

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

Для компаний, ориентированных в первую очередь на продукт – целевая аудитория и рынок не являются важными. Особенно, если уровень конкуренции низкий, а потребность в продукте высокая. Для таких компаний заказчик является только инструментом для получения денег.

Сложные интеллектуальные продукты обладают большим количеством параметров, которые могут меняться в зависимости от факторов и запроса. Разобраться в этих параметрах, формулировках, технологиях и процессах неподготовленному человеку (большая часть заказчиков для IT продукта именно такая) и вникнуть во все нюансы – сложно. Именно поэтому, важно говорить с заказчиком на том языке, который он понимает. Из-за этого, а также ввиду непонимания важности рынка, отсутствия уважения/любви к потребителям и в целом эмпатии со стороны команд, занимающихся адаптацией it-продуктов, они после встреч и переговоров зачастую восклицают:

BunRouter это чрезвычайно быстрый Golang router с уникальной комбинацией возможностей: мидлвары, обработка ошибок, минималистическое и совместимое АПИ.

“Мои сотрудники всегда счастливы, но времени на работу у них не хватает”.

“Мои сотрудники работают хорошо, но не выглядят довольными”.

Знакомо? Наверняка! Так бывает, когда мы ошибаемся с необходимым уровнем внимания к сотрудникам.

Оно и понятно: внимания много – начинают страдать основные задачи, внимания мало – сотрудники грустят, эффективность падает. Баланс найти очень и очень сложно.

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

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

Хотите разобраться, как должен выглядеть правильный people management? Прошу под кат!

Формальной причиной появления этой статьи стала недавняя замечательная публикация "Электрический путь в век скоростей" в которой автор изложил исторические факты о первых, весьма не робких, шагах в развитии высокоскоростного железнодорожного сообщения, предпринятых в Германии в конце XIX начале XX века. Мне, как человеку некоторым образом связанному с железнодорожным транспортом, упомянутая статья понравилась тем, что она осветила, пусть и в публицистической форме, историю первого применения асинхронного двигателя в качестве тягового двигателя железнодорожного экипажа. Впечатляет и масштаб рекорда скорости, достигнутого электровагоном AEG - ведь, на минуточку, дело было в 1903 году! Такой успех технически во многом обусловлен применением именно бесколлекторного двигателя переменного тока.

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

Заказчик называет адрес … Как искусственный интеллект определит район, чтобы предложить интервалы доставки?

Представляю вашему вниманию ваш будущий маленький Teamviewer. Полностью открытый, с клиентами на все платформы. Заявлено небольшое потребление серверных ресурсов. Из коробки умеет ходить через наты, как любой уважающий себя AnyDesk. Поскольку ваш сервер, скорее всего ближе к вам географически, то и картинка будет передаваться быстрее, да и зашифрован трафик будет вами же.

На сайте есть документация по развертыванию сервера. Но я хочу docker-compose и поэтому иду за ним на гитхаб и меняю в нём две строки:
command: hbbs -r rustdesk.example.com:21117
command: hbbr
на
command: hbbs -r rustdesk.mysweetdomain.org:21117 -k _
command: hbbr -k _

Я указал свой доменный адрес, причём адреса внутри сети и снаружи у домена разные. Клиенты находящиеся как в моей сети, так и в интернете где-то за натом, несмотря на это, ходят друг другу в гости без проблем. И установил ключ -k _ для того, чтобы шифрование было обязательным. Если вы не будете указывать на клиенте публичный ключ сервера, то соединение не будет зашифровано. Можно и не шифроваться, но почему бы и нет? Да и лишний никто не присосётся.

Далее взмах docker-compose и сервер уже работает и слушает локальные порты. Пробрасываем на роутере 21115,21116,21117,21118,21119 tcp и 21116 udp.

В докере, запущено два контейнера hbbs и hbbr, надо войти в оба из них и посмотреть что у них в файлах ./id_ed25519.pub и ./id_ed25519. Вам нужно сделать так, чтобы в обоих контейнерах эти пары файлов были одинаковыми, иначе вы увидите эту ошибку. Содержимое ./id_ed25519 - это и есть ключ. Его надо поместить вот сюда: