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

Прошло уже 6 лет с момента выхода первой и последней заметки по этому проекту(Свой 2-тактный мотор. CR620 рекомендуется к ознакомлению). Тогда я остановился из-за проблем с аутсорсом в металлообработке. Кто не может, кто не хочет, кто делает бесконечно долго, кто и детали назад возвращать не хочет. А город в котором я живу имеет славную промышленную историю и был центром Петровской индустрии 18-века, но от славного прошлого ныне остался один корень в названии города и несколько действующих предприятий, на которых занято порядка единиц процентов населения. А сейчас не 90-е и даже не 00-е, когда можно было договорится с человеком с завода чтобы он что-то такое эдакое для тебя сделал. Теперь у них есть работа и КПП на входе, как я потом узнал — номинальное. Вся эта история с передачей деталей где они лежат, а не делаются, поиск новых мест и тому подобное блуждание длилась несколько лет. Оказалось, что отлить сложную алюминиевую отливку у сарая на родительской даче я смог, а обработать, что не выглядело проблемой изначально — нет.

Знакомо, узнали?

Каждый раз когда вы пытались объявить опциональное замыкание @escaping в Swift компилятор ругался и писал непонятную ошибку @escaping attribute only applies to function types. Мне это не нравилось, и я решил это исправить. Теперь компилятор Swift 5.3 вместо этой ошибки напишет Closure is already escaping in optional type argument.

И сегодня мы разберемся, как сделать свой вклад в развитие языка Swift.

В общем, выскажу своё никому не нужное мнение по поводу того, что происходит с Яндекс.Диском в последние дни. И, мне кажется, что может сложиться впечатление, особенно после прочтения этой статьи, что я состою в рядах так называемых "хейтеров" компании, но это совсем не правда. Я даже исправно плачу каждый месяц три копеечки из своего кармана за подписку ПЛЮС, хотя фактически ею не пользуюсь. Вполне очевидно, что такие компании-титаны как Яндекс, Сбер и Mail Ru Group двигают ИТ в нашей стране семимильными шагами и, что уж говорить, про то количество рабочих мест, которые они обеспечивают, часто на очень комфортных условиях, позволяя людям участвовать в технологически крутых продуктах. Далее по тексту Mail Ru буду называть MRG.

Сап, котятки.

Я пришёл рассказать о проекте UAVCAN — новом сетевом стандарте для организации взаимодействия узлов и компонентов современных транспортных средств с высоким уровнем автономности/автоматизации. Название является акронимом от Uncomplicated Application-level Vehicular Computing And Networking (несложные бортовые сети и коммуникации уровня приложения).

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

Конъюнктура

Первый блин проекта был заложен в 2014-м. С самого начала это был эксперимент в минимализме: возможно ли в разработке сложных распределённых бортовых систем опираться на мощные абстракции, избегая при этом роста сложности реализации и связанных с ним трудностей валидации и верификации.

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

В первой из серии статей о GC я представил сборщик мусора в языке D и возможности языка, которые его используют. Два ключевых момента, которые я пытался донести:

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

   
   

2. Простые стратегии выделения памяти в стиле C и C++ позволяют уменьшить нагрузку на GC. Не выделяйте память внутри циклов — вместо этого как можно больше ресурсов выделяйте заранее или используйте стек. Сведите к минимуму общее число выделений памяти через GC. Эти стратегии работают благодаря пункту № 1. Разработчик может диктовать, когда допустимо запустить сборку мусора, грамотно используя выделение памяти из кучи, управляемой GC.

   
   

Вероятно, долгожданный момент, о котором я сегодня буду говорить, был в каком-то смысле неизбежным. Годами ходили слухи о том, что Apple воспользуется накопленными знаниями об архитектуре процессоров ARM и перенесёт её в настольные компьютеры и ноутбуки. На недавней виртуальной конференции Worldwide Developers Conference производитель iPhone выступил именно с таким заявлением. Разумеется, многих заинтересовали дальнейшие действия Intel — отвергнутого партнёра, отношения с которыми привели к решению Apple о вертикальной интеграции. Но мне больше любопытно проследить за угасанием платформы, которую Intel победила, чтобы добиться расположения Apple, а также увидеть параллели, постепенно возникшие между PowerPC и Intel. Сегодня мы расскажем о длинном списке производителей процессоров, к которым охладела Apple, на примере перехода с PowerPC на Intel. Если вы разочаруете Apple, вам не поздоровится.

Многие из вас, дорогие читатели, слышали о Деннисе Ритчи. В конце 1960-х он оставил аспирантские исследования в области прикладной математике в Гарварде ради должности в Bell Telephone Laboratories, где и проработал всю жизнь. Вскоре после поступления на работу в Labs Ритчи объединил свои усилия с Кеном Томпсоном для создания фундаментальной пары, породившей весь последующий цифровой мир: операционной системы Unix и языка программирования C. Томпсон вёл разработку ОС, а Ритчи занимался созданием C, на котором Томпсон переписал Unix. В то время Unix стал основой для большинства операционных систем, из которых строился наш цифровой мир, а язык C стал (и по-прежнему остаётся) одним из самых популярных языков для создания ПО, приводящего этот мир в движение.


Создатели Unix Кен Томпсон и Деннис Ритчи. Источник фотографии неизвестен.

На личных веб-страницах Ритчи сайта Labs (которые до сих пор поддерживает текущий владелец Nokia), он описывает в характерном ему сухом и уничижительном стиле своё путешествие в академический мир компьютерных наук:

«Я… получил степень бакалавра и учёную степень в Университете Гарварда, где студентом занимался физикой, а аспирантом — прикладной математикой… Темой моей докторской диссертации 1968 года были подрекурсивные иерархии функций. Опыт моей студенческой учёбы убедил меня, что я недостаточно умён для физика, и что компьютеры — это довольно любопытно. Мой аспирантский опыт убедил меня, что я недостаточно умён, чтобы стать специалистом в теории алгоритмов, и что мне больше нравятся процедурные, а не функциональные языки»¹.

Изображение предоставлено автором. Основано на фотографии Патрика Томаса с Ансплэша

Это перевод статьи Дэвида Клира о методе ведения заметок Zettelkasten, благодаря которому немецкий социолог Никлас Луман написал более 70 книг и 400 научных статей. Стоит читать, если вы хотите создать собственную базу знаний, систематизировать идеи и перестать забывать важные мысли.

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

У меня есть цель — разобраться в том, что же происходило в 60-70-е годы в Xerox PARC и в окрестностях, как так вышло, что несколько коллективов инженеров, работая рука об руку, создали невероятные технологии, которые определили наше настоящее, а их идеи будут определять будущее. Почему этого не происходит сейчас? (а если происходит, то где?). Как собрать подобный коллектив? Где же мы повернули не туда? Какие идеи мы пропустили, а стоило бы к ним повнимательнее присмотреться?

Предлагаю вашему вниманию перевод начала большого текста Алана Кея (150 000 знаков), на который он неоднократно ссылается во всех своих выступлениях и ответах на Quora и HackerNews.

Кто готов помогать с переводом — пишите в личку.

• Аннотация и Введение

I. 1960–66 — Становление ООП и другие новые идеи 60-х

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

Любая новинка проходит несколько стадий принятия — как своими создателями, так и всеми остальными. Вот как это происходит у создателей. Сначала они замечают, что в разных проектах используется будто бы тот же подход. Позднее их предположения подтверждаются, но пока никто не осознает грандиозного значения новой модели. Затем происходит великий сдвиг парадигмы и модель становится новым способом мышления. И наконец она превращается в закостенелую религию, от которой сама и произошла. Все остальные принимают новинку по Шопенгауэру: сперва ее осуждают, называя безумной; через пару лет ее уже считают очевидной обыденностью; в конце концов те, кто ее отвергал, объявляют себя ее создателями.

Мы уже писали о сборке мусора для JavaScript, о DOM, и о том, как всё это реализовано и оптимизировано в JS-движке V8. Правда, Chromium — это не только JavaScript. Большая часть браузера и движок рендеринга Blink, куда встроен V8, написаны на C++. JavaScript можно использовать для работы с DOM, а на экран изменения выводятся с использованием конвейера рендеринга.

Так как граф C++-объектов, имеющих отношение к DOM, тесно связан с JavaScript-объектами, команда разработчиков Chromium пару лет назад начала использовать для управления памятью, в которой хранятся эти объекты, сборщик мусора, названный Oilpan. Oilpan — это сборщик мусора, написанный на C++ и предназначенный для управления C++-памятью, которая может быть подключена к V8. Управление памятью осуществляется с использованием технологии кросс-компонентной сборки мусора. В рамках этой технологии граф связанных C++/JavaScript-объектов рассматривается как единая куча.



Этот материал является первой публикацией, посвящённой Oilpan. Здесь будет сделан обзор основных принципов, лежащих в основе данного сборщика мусора, а также — C++-API Oilpan. Мы рассмотрим некоторые возможности, поддерживаемые Oilpan, расскажем о том, как устроена работа различных подсистемам сборщика мусора. Тут же мы разберём процесс конкурентного освобождения памяти, занятой объектами.

Самое интересное здесь то, что система Oilpan является частью Blink, но сейчас осуществляется её перевод в V8, где она будет представлена в форме библиотеки для сборки мусора. Цель этого всего заключается в том, чтобы облегчить доступ к C++-механизмам сборки мусора всем тем, кто встраивает в свои платформы движок V8. Кроме того, то, что Oilpan станет библиотекой, позволит пользоваться этой системой абсолютно всем заинтересованным в ней C++-программистам.

Ссылка на первую часть

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



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

И еще одно. Я — художник. Будет много картинок, и даже видео. Трафик!

Нередко вижу слова в духе «по другим отраслям коронавирус сильно ударил, а вот IT практически не затронул». Мол, веб-сервисы от карантина только выиграли, писать код можно и удалённо, а раз сейчас ограничения отменяют — значит, всё закончилось хорошо, проблем нет и теперь уже не будет.

По-моему, заявлять такое означает не вполне понимать ситуацию. Существует, например, прогноз Минкомсвязи, что российская IT-отрасль может стать убыточной, а численность российских айтишников во втором полугодии может снизиться на 27 000 человек. Понятия не имею, насколько сбудется конкретно этот прогноз, но поискал разные данные, и в целом они подтверждают: хотя IT и повезло больше многих, картина невесёлая, а уверенно говорить «всё осталось позади» рано.

Как всё могло ухудшиться в период, когда популярность онлайн-сервисов резко возросла? Как происходящее может сказаться на обычном айтишнике? И что ему делать, чтобы сложности задели как можно меньше?

Несколько приёмов для создания произведений процедурального (генеративного) искусства.



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

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

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

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

В прошлом году я участвовал в соревнованиях JS13K 2019, на которых людям предлагается разрабатывать игры в менее чем 13 КБ кода на JavaScript. Я участвовал с клоном Doom, который назвал… «Ещё один клон Doom» (Yet Another Doom Clone).


Поиграть в него можно здесь. Исходный код выложен сюда.

Зачем создавать клон Doom?

Зачем писать FPS на JavaScript всего в 13 КБ (с учётом сжатия)? По нескольким причинам. Но лучше всего на этот вопрос отвечает раздел FAQ соревнований JS13K «Можно ли использовать WebGL?»:

«Да, но может быть сложно уместить его в 13 килобайта, если вы планируете писать FPS».

Кроме того, в то время я как раз написал 3D-рендерер и хотел поработать над ним ещё. К тому же мне нравится создавать сильно сжатый код. (Например, много лет назад я создал язык и написал компилятор для нового языка, предназначенный специально для использования в код-гольфинге.)

Именно поэтому я выбрал FPS. Остаётся вопрос: «Почему Doom?» На него ответить проще: если вы хотите написать FPS, и чтобы он при этом был небольшим, то Doom — практически самый минималистичный вариант.

Месяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)

Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:

1. С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
2. Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
3. Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
4. Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)

Начну со статистики по мартовскому релизу LLVM 10.0:
В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.

А вот распределение по числу инструкций:

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

Этот пост не о языке и не о фреймворке. Мы будем говорить только о технике.

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

До того, как Loki.ai стал финансово устойчивой компанией, я потерпел неудачу с первыми 5 стартапами за 5 лет.

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

Я запустил свой первый «бизнес» когда я еще учился в школе в 2009 году. Я занимался продажей футболок и доход нашей команды составлял 25 000 долларов. Но несмотря на доход, нам так и не удавалось получить какую-либо прибыль. В свои 17 лет я почему то стал считать, что разобрался в том, как делается бизнес. Но позже я понял, что продавать на площадках, где вы не пользуетесь популярностью и известностью, далеко не тоже самое что продавать футболки друзьям в школе. Это был мой самый первый опыт.

С момента окончания школы я запустил 6 стартапов и с треском провалился в 5 из них.



Все 5 неудач имели разные причины. Но уроки, которые я извлек из них, помогли на шестой попытке сделать то, что долго не удавалось (3 года и более).

Источник всех утверждений статьи взят из данной видео-конференции Левика. В ней язык живой, а не "доклад под бумажку". Не поленитесь послушать, чтобы заранее не писать глупости (про теорию заговора и аргессивного продвижения).

Независимо от того, сколько вложений компании-разработчики могут потратить на инструментарий и обучение своих разработчиков, «C++, по своей сути, не является безопасным языком», сказал Райан Левик (Ryan Levick) 'cloud developer advocate' из Microsoft на виртуальной конференции AllThingsOpen в прошлом месяце, объясняя в виртуальной беседе почему Microsoft постепенно переходит с C/C++ на Rust для создания своего инфраструктурного программного обеспечения. И вдохновляет других гигантов индустрии программного обеспечения задуматься о том же.

Всем привет!

Два месяца назад я и мой знакомый (для краткости, назовем его Илья) запустили свой стартап.
Пффф… Скажите вы. Каждый день кто-то что-то запускает. Кто-то запускает в одиночку. Некоторые кучкуются в команды. У кого-то есть деньги на разработку\маркетинг, кто-то предлагает долю, пост-оплату, опционы. Все крутятся как могут и ищут партнеров также.


У нас не было денег, был лишь опыт и 2 недели до первых продаж.

Под катом я расскажу о том, с чем мы столкнулись и как заработали миллион в кризис