Как стать автором
Обновить
4
0
Alexander Irbis @BlessMaster

Разработчик

Отправить сообщение

Rust должен умереть, МГУ сделал замеры

Время на прочтение 25 мин
Количество просмотров 99K

В предыдущих сериях:



Медленно, но верно Раст проникает не только в умы сотрудников больших корпораций, но и в умы школьников и студентов. В этот раз мы поговорим о статье от студента МГУ: https://rustmustdie.com/.


Её репостнул Андрей Викторович Столяров, доцент кафедры алгоритмических языков факультета ВМК МГУ им. М. В. Ломоносова и по совместительству научрук студента-автора статьи.


Я бы сказал, что тут дело даже не в том, что он "неинтуитивный". Дело скорее в том, что компилятор раста сам решает, когда владение "должно" (с его, компилятора, точки зрения) перейти от одного игрока к другому. А решать это вообще-то должен программист, а не компилятор. Ну и начинается пляска вида "как заставить тупой компайлер сделать то, чего я хочу".
Бред это всё.

— А. В. Столяров
Кощунство!
Всего голосов 363: ↑344 и ↓19 +325
Комментарии 230

Как тимлиду можно развивать команду

Время на прочтение 6 мин
Количество просмотров 4.2K
Гораздо приятнее руководить командой опытных разработчиков, а не командой новичков. Однако на рынке труда очень мало опытных разработчиков, у них большие запросы и за них огромная конкуренция. Что делать? Один из способов — вырастить своих сеньоров из мидлов и джунов. В этой статье я опишу свои методики как можно ускорять профессиональный рост сотрудников. Это не окончательный список, не какой-то стандарт, а просто описание моего опыта руководства двумя командами разработки. Методы работают у меня, значит возможно сработают и у других. Просьба коллег тоже делиться своими подходами в комментариях. Итак, поехали.
Читать дальше →
Всего голосов 8: ↑6 и ↓2 +4
Комментарии 0

Локальный TCP Anycast — это действительно сложно

Время на прочтение 4 мин
Количество просмотров 3.3K

Pete Lumbis и Network Ninja в своих комментариях к моим записям, посвященным UCMP, упомянули интересный случай использования UCMP в центре обработки данных: а именно серверы anycast.

Вот типичный сценарий, который они упомянули: группа серверов, случайно подключенных к нескольким leaf-коммутаторам, предоставляет услугу на одном и том же IP-адресе (отсюда и происходит anycast).

Читать далее
Всего голосов 5: ↑4 и ↓1 +3
Комментарии 0

Consul: Service Discovery это просто, или прощаемся с конфиг-файлами

Время на прочтение 8 мин
Количество просмотров 125K
Что здесь интересного:

image

Обзорная статья о Consul (http://consul.io) — системе для поддержания обнаружения сервисов и распределенного хранилища ключ-значение. Кроме самого Consul, рассмотрим Consul-Template — средство для управления конфигурациями сервисов автоматически отражающее изменения в топологии. Статья будет интересна DevOps инженерам, системным архитекторам, тим-лидам проектов и прочим интересующимся микросервисными архитектурами.
Читать дальше →
Всего голосов 15: ↑15 и ↓0 +15
Комментарии 28

Всё, что нужно знать об автоматических переносах в CSS

Время на прочтение 6 мин
Количество просмотров 46K


Недавно меня пригласили выступить с вечерней лекцией в Типографском обществе Австрии. Для меня стало большой честью последовать по стопам таких светил, как Мэтью Картер, Вим Краувел, Маргарет Калверт, Эрик Шпикерман и покойная Фреда Сэк.

Я рассказал о некоторых золотых правилах типографики в интернете, а потом во время секции QA меня спросили о текущей ситуации с автоматическими переносами в вебе. Это хороший вопрос, особенно с учётом того, что немецкий язык знаменит часто используемыми длинными существительными (например, Verbesserungsvorschlag означает «предложение для улучшения»), поэтому переносы широко используются в большинстве письменных носителей.
Читать дальше →
Всего голосов 31: ↑31 и ↓0 +31
Комментарии 11

Postgresso 35 — спецвыпуск: PostgreSQL 14

Время на прочтение 13 мин
Количество просмотров 6.3K


Пресс-релиз PostgreSQL обширен и основателен. Есть и выжимка (highlights), в которой после бурных обсуждений в рассылках выделили главное.

Статей о 14-й много. Мы смотрели и разрозненные статьи и целые сериалы:
обзоры коммитфестов Павла Лузанова (5 серий),
waiting for PostgreSQL 14 Хуберта 'depesz' Любашевского (18),
микрообзоры Postgres 14 highlights Мишеля Пакье (Michael Paquier) (5),
в блоге Fujitsu OSS (5).

Кроме того есть пространная статья-справочник от HPE: PostgreSQL 14 New Features With Examples (Beta 1).

Начнём со статей, в которых авторы стараются охватить версию 14 в целом. Но перед этим разомнёмся

в облаках и контейнерах

Читать дальше →
Всего голосов 16: ↑16 и ↓0 +16
Комментарии 1

Соотношение «цена-прибыль» Шиллера и пузыри на рынке акций

Время на прочтение 20 мин
Количество просмотров 22K
Адриан Ханнеман. Два мальчика, выдувающие пузыри. ок. 1630 г. Музей искусств Нортона, Уэст-Палм-Бич.

Пару месяцев назад на Хабре вышла статья «На фондовом рынке США сформировался пузырь небывалых размеров». Согласно этой статье, «мультипликаторы находятся на исторических максимумах», так что «большой кризис неизбежен».

Один из мультипликаторов, на который ссылается статья — это известное соотношение «цена-прибыль» Шиллера. Честно говоря, я уже сбился со счёта, сколько раз за последние годы я читал апокалиптические прогнозы, основанные на индикаторе Шиллера. Чтобы выяснить, насколько можно верить этим прогнозам, я решил наконец-то почитать работы Шиллера и других исследователей. Оказалось, что недавно даже сам Шиллер написал, что такой прямолинейный взгляд на показатель «цена-прибыль» может быть весьма спорным.

В этой статье я расскажу, как устроен многострадальный индикатор Шиллера, почему сам Шиллер не вполне поддерживает всёпропальщицкие предсказания, есть ли статистическая связь между индикатором и долгосрочной доходностью рынка акций, и можно ли на ней заработать. Спойлер: скорее всего, философский камень инвестиций всё ещё не найден, а высокое соотношение «цена-прибыль» в первую очередь связано с низким процентными ставками.
Читать дальше →
Всего голосов 43: ↑43 и ↓0 +43
Комментарии 26

Как пересчитать электронную таблицу

Время на прочтение 13 мин
Количество просмотров 6.3K
Предположим, я заказываю буррито для двоих друзей и хочу рассчитать общую стоимость заказа:



Поток данных в этой таблице немного сложно проследить, поэтому вот эквивалентная диаграмма, которая представляет таблицу в виде графа:



Округляем стоимость буррито El Farolito super vegi до 8 долларов, поэтому при доставке стоимостью 2 доллара общая сумма составит 20 долларов.
Читать дальше →
Всего голосов 22: ↑21 и ↓1 +20
Комментарии 6

Многомерные данные и оценка качества их визуализации

Время на прочтение 5 мин
Количество просмотров 3.5K
image

  • Многомерные данные — что они из себя представляют?
  • Зачем их визуализировать и что мы можем понять из визуализации?
  • Какими способами можно уменьшить размерность таким образом, чтобы сохранилась главная структура данных и какие свойства учитывать при проектировании?
Читать дальше →
Рейтинг 0
Комментарии 1

Смарт контракты Ethereum: структурируем токены как акции

Время на прочтение 9 мин
Количество просмотров 28K
В настоящее время идет настоящая волна хайпа криптовалют и череда успешных ICO самых разнообразных проектов, в том числе имеющих весьма сомнительное или не имеющих вообще никакого отношения к децентрализации и другим базовым принципам блокчейн. В ходе ICO на продажу широкой публике выставляются некие виртуальные сущности – токены. Наполнение этих самых токенов какой-либо реальной «ценностью», как правило, уникально для каждого проекта. В рамках данной статьи я хочу рассмотреть структурирование токена как «акции», когда держатель этих токенов претендует на получение дивидендов от проекта, пропорционально имеющемуся у него проценту токенов от общей эмиссии. Это создает целый ряд правовых коллизий и неопределенностей, поэтому на сегодня нет ни одного крупного проекта, построенного по этой логичной и понятной для инвесторов модели, но юридические аспекты мы вынесем за скобки и остановимся лишь на технической реализации.
Читать дальше →
Всего голосов 12: ↑10 и ↓2 +8
Комментарии 9

Смарт контракты Ethereum: что делать при ошибке в смартконтракте или техники миграции

Время на прочтение 7 мин
Количество просмотров 10K
При написании смартконтрактов важно помнить, что после загрузки в блокчейн, они уже не могут быть изменены, а следовательно, не могут быть внесены какие-либо улучшения или исправлены какие-то найденные ошибки! Все мы знаем, что ошибки есть в любой программе, а вернувшись к написанному пару месяцев назад коду мы всегда найдем, что там можно улучшить. Как же быть? Единственно возможный вариант – это загрузить новый контракт с исправленным кодом. Но как же быть, если на базе имеющегося контракта уже выпущены токены? На помощь нам приходит миграция! За последний год я попробовал много разных техник ее реализации, проанализировал применяемые в других крупных блокчейн проектах и что-то поизобретал сам. Подробности под катом.

Читать дальше →
Всего голосов 18: ↑16 и ↓2 +14
Комментарии 0

Безынерционное измерение температуры воздуха ультразвуком

Время на прочтение 2 мин
Количество просмотров 157K

Привет, Хабр.

Люблю нестандартные решения. Cейчас я покажу, как измерять температуру воздуха с помощью ультразвука.
Читать дальше →
Всего голосов 183: ↑169 и ↓14 +155
Комментарии 88

Как развитие алгоритмов сжатия остановилось 20 лет назад, или о новом конкурсе на 200 тысяч евро

Время на прочтение 18 мин
Количество просмотров 70K

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

Пост набрал 206 «плюсов», вышел на 2 место топа недели и вызвал оживленную дискуссию, в которой мне больше всего понравился комментарий: «Коммерческого интереса эффективность по сжатию алгоритмов сжатия без потерь сегодня не представляет, в силу отсутствия принципиально более эффективных алгоритмов. Деньги сегодня — в сжатии аудио-видео. И там и алгоритмы другие. Тема сжатия без потерь удобна именно лёгкостью верификации алгоритма, и не слегка устарела. Лет на 20.» 

Поскольку я сам уже 20 лет в области сжатия видео, с ее бурным развитием мне спорить сложно. А вот что сжатие без потерь развиваться перестало… Хотя логика тут понятна каждому. Я до сих пор пользуюсь ZIP, все мои друзья пользуются ZIP с 1989 года — значит, ничего нового не появляется. Так ведь? Похоже рассуждают сторонники плоской земли. ))) Я не видел, знакомые не видели, и даже некоторые авторитеты утверждают, значит, это так! 

О том, как Intel просили меня не прекращать читать курс по сжатию, ибо людей нет новые алгоритмы делать, я в прошлый раз писал. Но тут и Huawei в ту же дуду дует! Вместо того, чтобы раздать призы и должности победителям, а затем успокоиться, поскольку развитие давно встало, эти эксцентричные люди посчитали конкурс крайне успешным и запустили новый с призовым фондом 200 тысяч EUR.

Развивались ли алгоритмы сжатия без потерь в последние 20 лет? Чем закончился прошлый конкурс и на сколько опередили baseline? Сколько денег получили русские таланты, а сколько зарубежные? И есть ли вообще жизнь на Марсе в сжатии без потерь? 

Кому интересно — добро пожаловать под кат! 
Читать дальше →
Всего голосов 259: ↑258 и ↓1 +257
Комментарии 134

Объяснение легковесных потоков в 200 строк на Rust

Время на прочтение 26 мин
Количество просмотров 12K

Объяснение легковесных потоков в 200 строк на Rust


Легковесные потоки (ligthweight threads, coroutines, корутины, green threads) являются очень мощным механизмом в современных языках программирования. В этой статье Carl Fredrik Samson попытался реализовать рантайм для легковесных потоков на Раст, попутно объясняя, как они устроены "под капотом".


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


Переводил для себя большей частью. Обо всех замечаниях пишите — оперативно исправлю. Старался переводить близко к тексту, но в некоторых местах переформулировал, чтобы читалось легче и было понятнее.
Читать дальше →
Всего голосов 25: ↑25 и ↓0 +25
Комментарии 8

Алгоритм Верхуффа для произвольной чётной системы счисления

Время на прочтение 4 мин
Количество просмотров 12K
КДПВ Иногда возникает задача защитить строку-идентификатор от случайных ошибок, сделанных человеком. Например, номер платёжной карты. Для этого к строке добавляется вычисленная специальным образом контрольная цифра, и когда человек вводит этот номер, можно сделать первичную проверку на ошибки без обращения к базе данных. Самый простой вариант — добавить остаток от деления суммы всех цифр на 10, в таком случае искажение любой одной цифры (в том числе контрольной) будет легко обнаружить, и такая строка не пройдёт проверку. Но некоторые другие ошибки такая контрольная сумма пропустит, например, перестановку двух цифр местами, а это тоже довольно распространённая ошибка.
Читать дальше →
Всего голосов 41: ↑40 и ↓1 +39
Комментарии 15

Так ли токсичен синтаксис Rust?

Время на прочтение 19 мин
Количество просмотров 49K
fn main() {
  println!("Hello, Rust!");
  println!("... Goodbye!");
}

Синтаксис — это первое, на что обращают внимание разработчики, впервые столкнувшись с кодом на Rust. И сложно найти что-то другое, что вызывало бы больше негодования у новичков, и при этом такое, к чему совершенно спокойно относятся уже "понюхавшие пороха" Rust-программисты. Посмотрите, например, сколько эмоций вызывает синтаксис Rust у комментаторов одной из типичных новостей про Rust на OpenNET:

Читать дальше →
Всего голосов 152: ↑136 и ↓16 +120
Комментарии 737

Современные накопители очень быстры, но плохие API это не учитывают

Время на прочтение 11 мин
Количество просмотров 14K


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

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

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

Вот самые распространённые примеры таких заблуждений:

  • «Вполне нормально скопировать память здесь и выполнить эти затратные вычисления, потому что это сэкономит нам одну операцию ввода-вывода, которая была бы ещё более затратной».
  • «Я проектирую систему, которая должна быть быстрой. Поэтому она должна находиться в памяти».
  • «Если мы разобьём эти данные на несколько файлов, то выполнение будет медленным, поскольку возникнут паттерны произвольного ввода-вывода. Нам нужно оптимизировать выполнение под последовательный доступ и осуществлять считывание из одного файла».
  • «Прямой ввод-вывод очень медленный. Он подходит только для очень специализированных областей применения. Если у тебя нет собственного кэша, ты обречён».

Однако если изучить спецификации современных NVMe-устройств, то мы увидим, что даже в потребительском классе это устройства с задержками, измеряемыми в единицах микросекунд, и пропускной способностью в несколько ГБ/с, поддерживающие несколько сотен тысяч произвольных IOPS. Так в чём же нестыковка?
Читать дальше →
Всего голосов 46: ↑42 и ↓4 +38
Комментарии 40

Возможно, вам не нужен Rust, чтобы ускорить ваш JS

Время на прочтение 32 мин
Количество просмотров 28K

Несколько недель назад я обнаружил пост "Окисляем Source Maps с Rust и WebAssembly"
распространяющийся по Твиттеру и расказывающий о выигрыше в производительности от замены обычного JavaScript в библиотеке source-map на Rust, скомпилированный в WebAssembly.


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


Так что я скачал библиотеку с GitHub и отправился в небольшое исследование производительности, которое я документирую здесь практически дословно.

Читать дальше →
Всего голосов 58: ↑54 и ↓4 +50
Комментарии 43

Пол Грэм «Как стать богатым» (глава из книги Hackers&Painters)

Время на прочтение 28 мин
Количество просмотров 12K
Это эссе было впервые опубликовано в книге Hackers & Painters, и в онлайн появилось только в декабре 2005 года. Я решил воскресить его с веб-архива, потому что это одно из самых важных эссе в моей жизни, а я сейчас делаю коллекцию лонгридов, которые оказали влияние на мировоззрение: проект Ontol

image

С чего бы вы начали, если бы вдруг решили разбогатеть? Я думаю, что самым лучшим решением было бы запустить новую компанию — стартап, или присоединиться к уже существующему. Этот способ показывает себя эффективным в течение сотен лет. Само слово «стартап» возникло в шестидесятые годы прошлого века, но то, что происходило в то время, было очень похоже на авантюрные торговые путешествия, которые предпринимались в средние века.

Обычно понятие стартап связано с высокими технологиями. Настолько сильно, что выражение «технологический стартап» — почти тавтология. Как правило, это небольшая компания, которая взялась за решение сложной технической проблемы.

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

Тезис


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

Давайте порассуждаем. Предположим, что вы хороший хакер (в первоначальном, положительном смысле этого слова) 20-25 лет.
Читать дальше →
Всего голосов 26: ↑23 и ↓3 +20
Комментарии 2

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность