Таким я себя видел в своих мечтах. Freepik

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

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

1. Думайте своей головой и проверяйте факты

Введение

Сложность

Логарифмы

Оптимальная сортировка

Автор Лысый Камрад (@LKamrad)

Осебергский корабль удивительно красив. Построенный двенадцать веков назад он выглядит так, как будто совсем недавно спущен на воду, такова его сохранность. Это не реконструкция– 90% деревянных деталей подлинные, даже 60% железных болтов* те же самые, что использовались при его постройке. Нос и корма судна украшены великолепной резьбой и имеют навершия спиральной формы, имитирующие хвост и голову дракона или морского змея.

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

Может показаться откровенной наглостью в наши дни утверждать, что Вы изобрели алгоритм сортировки, который на 30% быстрее, чем лучший существующий. Увы, я должен сделать гораздо более наглое заявление: я написал алгоритм сортировки, который в два раза быстрее, чем std :: sort для многих входных данных. И за исключением случаев, когда я специально конструирую воспроизведение нахудших для него ситуаций, алгоритм никогда не бывает медленнее, чем std :: sort (и даже когда попадаются эти худшие случаи, они обнаруживаются и происходит автоматический возврат к std :: sort).

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

В разные эпохи развития нашего проекта в качестве основного хранилища которое было как источник данных для аналитики у нас были хранилища MySQL, ElasitcSearch, Exasol и ClickHouse. Последний нам очень нравится и вообще вызывает дикий восторг как инструмент для работы с большими массивами данных, но если посчитать итоговую стоимость владения с учётом внедрения кластера, обучения и поддержки — лучше подумайте два раза, прежде чем тащить его в ваше стек. На наших объёмах данных вложенные усилия окупаются, но если бы мы были чуть меньше, то, наверное, экономика не сошлась бы.

Главная проблема ClickHouse — это практическое отсутствие удобных и стабильно работающих инструментов для эксплуатации и большое кол-во решение рядом в погоне добиться того же пользовательского опыта как при работе с классическим RDBMS (MySQL или PostgreSQL). Вам придется приложить не мало усилий чтобы понять как эффективно применить clickhouse для ваших задач анализировать придется много: начиная от вопросов развертывания до выбора оптимальных моделей данных под профиль вашей нагрузки, в общем доступе не так много рекомендаций по выбору конфигураций под разные типы задач.

С другой стороны, его киллер-фича — это возможность работать с огромными массивами данных невероятно быстро для решений в этой области, то что раньше нам приходилось делать в Spark или через другие реализации map reduce, теперь мы можем делать внутри clickhouse. И бесплатно, потому что такими же плюсами обладают многие MPP решения вроде Vertica или Exasol. Но ClickHouse открытый, и за это мы платим налог на использование не прогнозируемым объемом поддержки или развития системы. Не всем это подходит: например, есть опыт компаний, которые сначала было влезли в это дело, потом поняли, что это не то — и взяли платные продукты с платной поддержкой с экспертизой в решении архитектурных задач именно их продуктами. В платных продуктах есть готовые инструменты, которые понятно, как применять.

Давным-давно наш коллега @novar разместил на Хабре статью с описанием вот такого незатейливого ТЗ, полученного им от потенциального работодателя:

Реализовать класс для задания и расчета времени по расписанию. Расписание задано в стиле crontab (точный формат см. во вложении), требуется находить ближайшие в будущем или прошлом моменты, попадающие в это расписание. Обращаю Ваше внимание, что класс должен быть эффективным и не использовать много памяти и ресурсов даже тогда, когда в расписании задано много значений. Например очень много значений с шагом в одну миллисекунду.

Хочу предложить алгоритм, приближающийся к O(1) во всех возможных ситуациях, вместо оригинального O(n). Интересующихся прошу под кат.

Ах да. Если вы тот самый работодатель, вот готовый код под ваше ТЗ. Правда на Java, а не на C#. Но вы же не думали, что всё будет так просто?

Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion. И сегодня я хотел бы рассказать вам про микросервисы.

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

Досталась мне от бати книжка издания 1973 года, отпечатанная на ротапринте. Наткнулся в ней на вещи, которые бы мы сейчас назвали проблемой "выгорания". Термина в то время еще не было, но проблема была. Я выписал кое-какие вещи чисто для себя, но потом решил все же опубликовать, может кому пригодится...

Случай с бомжом

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

Обычно вместо денег я даю попрошайкам-мужчинам телефон отдела кадров одной курьерской компании, которая постоянно нуждается в сотрудниках. Но у него не было ног… Тогда я подумал: «Чувак, у тебя полным полно времени. Работа за компом — лучшее, что может случиться в твоей жизни. Купон со скидкой на курс по PHP — вот, что должны были положить тебе на койку туда, где раньше были ноги, когда ты очнулся после ампутации».

Я решил предложить ему изучить программирование. В его положении он должен был быть чертовски мотивирован. Но получится ли у него?

Всем привет! Меня зовут Дмитрий, я занимаюсь разработкой в области компьютерного зрения в команде MTS AI. Так исторически сложилось, что в своей работе я использую, как правило, связку устаревшей версии TensorFlow 1 и Keras. Пришло время двигаться дальше, но прежде чем полностью перейти на TensorFlow 2, я решил сравнить наиболее популярные на сегодня фреймворки глубокого обучения: TensorFlow и PyTorch. Эта статья будет полезна всем Data Scientist'ам, кто желает узнать чуть больше про особенности и производительность TensorFlow и PyTorch.

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

Мы поговорили с Алексеем Рембишем (/u/rembish/), который в Чехии вырос до руководителя бэкенд-разработки и архитектора ПО.

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

Будет много фото. Здесь есть, что показать!

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

Как это часто бывает, по-настоящему понимаешь какую-то тему, только когда начинаешь рассказывать о ней другим («метод Фейнмана»). Несколько друзей, позавидовав моим «успехам», попросили помочь разобраться с английским. Тут и обнаружилось, что хотя я уже успешно использую английский в повседневной работе, обучать ему кого-то ещё — это совершенно отдельный навык.

Первоначальная идея. Сначала разъяснить все английские времена за один присест удавалось, надёргав различных идей из интернета: обрывки чьих-то схем, начинали склеиваться в свою схему и обрастать собственными легендами, а применение времён почти всегда было проще пояснить, используя хрестоматийную «систему английских времен с точки зрения употребления глагола “to vodka”». С каждой новой импровизированной лекцией, схема и нарратив продолжали меняться. «Ученики» попадались с различным базовым уровнем, что позволило понять, откуда нужно начинать плясать, чтобы урок был понятен всем, кто хоть раз слышал что-то про глаголы have и be. Когда счёт обученных уже пошёл на десятки, я решил оформить идею в более стройную лекцию. От первых попыток преподавания английских времён, до этого момента прошло пять лет. За это время было обучено ещё пару сотен человек. Обучено — по приколу. Денег за эти уроки я не брал.