Две недели назад в Джэксонвилле встречался комитет стандарта ISO C++. Сегодня я хочу представить короткую сводку и написать о революционном решении, принятом на собрании в Джэксонвилле. Для получения дополнительной информации я рекомендую к прочтению статью C++ больше не будет иметь указатели. Комитет по стандартизации языка принял решение о том, что указатели будут объявлены устаревшими в C++20 и с большой долей вероятности будут удалены из C++23.

Откровенно говоря, то, что кажется революционном, — всего лишь последний шаг длинной эволюции.

^{Вот что будет, если ударить по стеклянным очкам молотком, но про это позже}

Чуть больше полугода назад меня вдруг пробило на хорошие очки. Я начал задавать одинаковые тупые вопросы и получать разные ответы. Кого о чём не спросишь — их технология лучшая в мире. Правда, после слов «обоснуйте, пожалуйста», начинаются проблемы с пруфами. В итоге дорога приключений привела меня довольно далеко.

Значит, два важных момента. Первый: оказывается, надо делать полную коррекцию, частичная — в большинстве случаев зло. Доказательство «в Европе уже давно так не делают» меня не устроило, поэтому пришлось копать исследования. Второй момент — долбанный светофильтр «для компьютера», отсекающий синий, всё же нужен. Но только, как мне кажется, не для компьютера. Тоже нашлись результаты, но на животных.

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

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

А знаете, что такое большая компания? Это когда ты не знаешь в лицо кого-то. Когда в команде есть люди, которые работают по должностным обязанностям без понимания, для чего нужна их работа. Когда простая задача «напечатайте табличку с текстом в магазин» начинает гулять по согласованиям и решается за 22 дня. Реальный случай. Это когда договор подписывается 4 месяца. И куча других приколов звериного оскала бюрократизма.

Разгребать всё это… хм, ну, скажем, увлекательно.

Всем привет! Мы на проекте ГИС ЖКХ используем PostgreSQL и недавно столкнулись с проблемой долгого выполнения SQL скриптов из-за быстрого увеличения объема данных в БД. В феврале 2018 года на PGConf я рассказал, как мы решали эту проблему. Слайды презентации доступны на сайте конференции. Предлагаю вашему вниманию текст моего выступления.

Перевод ироничного поста из блога Боба Мартина в котором он рассуждает о том, насколько неудачным является использование слова interface в современных языках программирования, и какую путаницу и проблемы оно несёт разработчикам.

— Что ты думаешь об интерфейсах?

— Имеешь в виду интерфейсы в Java или C#?

— Да. Классная фича этих языков?

— Просто великолепная!

— Правда? А что такое интерфейс? Это то же самое что и класс?

— Ну… Не совсем!

В 2020 году библиотека Natasha значительно обновилась, на Хабре опубликована статья про актуальную версию. Чтобы использовать инструменты, описанные в этом тексте, установите старую версию библиотеки pip install natasha<1 yargy<0.13.

Раздел про Yargy-парсер актуален и сейчас.

Есть стандартная задача извлечения именованных сущностей из текста (NER). На входе текст, на выходе структурированные, нормализованные объекты, например, с именами, адресами, датами:



Задача старая и хорошо изученная, для английского языка существует масса коммерческих и открытых решений: Spacy, Stanford NER, OpenNLP, NLTK, MITIE, Google Natural Language API, ParallelDots, Aylien, Rosette, TextRazor. Для русского тоже есть хорошие решения, но они в основном закрытые: DaData, Pullenti, Abbyy Infoextractor, Dictum, Eureka, Promt, RCO, AOT, Ahunter. Из открытого мне известен только Томита-парсер и свежий Deepmipt NER.

Я занимаюсь анализом данных, задача обработки текстов одна из самых частых. На практике оказывается, что, например, извлечь имена из русского текста совсем непросто. Есть готовое решение в Томита-парсере, но там неудобная интеграция с Python. Недавно появилось решение от ребят из iPavlov, но там имена не приводятся к нормальной форме. Для извлечения, например, адресов («ул. 8 Марта, д.4», «Ленинский проезд, 15») открытых решений мне не известно, есть pypostal, но он чтобы парсить адреса, а не искать их в тексте. C нестандартными задачами типа извлечения ссылок на нормативные акты («ст. 11 ГК РФ», «п. 1 ст. 6 Закона № 122-ФЗ») вообще непонятно, что делать.

Год назад Дима Веселов начал проект Natasha. С тех пор код был значительно доработан. Natasha была использована в нескольких крупных проектах. Сейчас мы готовы рассказать о ней пользователям Хабра.

Natasha — это аналог Томита-парсера для Python (Yargy-парсер) плюс набор готовых правил для извлечения имён, адресов, дат, сумм денег и других сущностей.

В статье показано, как использовать готовые правила из Natasha и, самое главное, как добавлять свои с помощью Yargy-парсера.

Я люблю делать простые как топор вещи, но одновременно жутко полезные, например, как прошлая статья 9 летней давности — Установка Ubuntu Linux с винчестера. Скрипт, вот и сейчас настал час для такой деятельности.
Под катом вы найдете подробнейшую инструкцию как на основе Arduino и дешевых и доступных средств автоматизировать подачу чистой свежей воды в кофемашину, а также организовать отвод жидкости из поддона кофемашины, на которой не предусмотрено подключение к внешним коммуникациям.

Ни для кого не секрет, что .net сейчас используется в большинстве случаев как инструмент бэкенд разработки, а в клиентской разработке последние лет 5 правит js сообщество с своей экосистемой и инструментами для разработки. Это все безобразие с каждым годом усиливает пропасть между фронтэндом и бэкендом, и планка вхождения в область становится все выше и выше, разработчики начинают делиться на два лагеря и уходит такое понятие как фуллстек.

Да, под Node.js можно написать сервер, но для бэковой разработки, все же, .net бесспорный лидер. На js, на мой взгляд, очень сложно написать гибкий и легко поддерживаемый бэкенд, хотя возможно многие со мной и не согласятся.

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

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

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

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

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

Darwin Information Typing Architecture (DITA) — XML-технология для автоматизации процессов, связанных с технической документацией. За время существования DITA накопилось большое количество разнообразных возможностей, подходов к организации контента, а также конкретных механизмов их реализации. Запутаться в них немудрено, и это часто приводит к появлению непонятных, неэффективных и просто неудобных решений по автоматизации документирования. Директор по проектам компании «Философт» Михаил Острогорский раскладывает всё по полочкам.

Предисловие

Предлагаемая статья написана по мотивам небольшого доклада, сделанного автором на одном из «Гипербатонов», которые время от времени бывают в Яндексе. Не то что бы я был слишком недоволен собой как оратором, но в этом случае публиковать дословную расшифровку устной речи — не лучшая идея, на мой взгляд.

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

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

На Хабре незамеченным прошел выход 3-й версии Wine — открытой реализации Win32 API. Трудно найти другой проект с открытыми исходниками, за исключением ядра, который бы так много значил для пользователей Linux, MacOS, FreeBSD и других POSIX-совместимых ОС. Каждый успех разработчиков Wine приводит к тому, что множество новых игр и приложений становятся доступны для пользователей Linux.

В этом плане Wine 3.0 явно не разочаровал: поддержка Direct3D 10 и 11, графический драйвер Android, поток команд Direct3D, реализован криптографический стандарт AES, новый уровень поддержки Direct Write и Direct2D — вот основные результаты. По итогам более 6000 внесенных правок произошло много интересного, включая переход дефолтной версии с Windows XP на Windows 7.

• 4586 приложений с высшим, платиновым статусом. Работают без нареканий.
• 3918 приложений с золотым статусом. При минимальных настройках и внешних DLL работают без нареканий.

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

Наверное каждый разработчик на определенном этапе задумывался о собственном IoT-проекте. Internet of Things сейчас поистине вездесущ и многим из нас хочется попробовать свои силы. Но не все знают, с чего начать и за что браться в первую очередь. Сегодня давайте посмотрим, как легко и непринужденно запустить свой собственный IoT-проект под Raspberry Pi 2, используя Windows 10 IoT Core и DeviceHive.

Деплоим Windows 10 приложения на Raspberry Pi 2

Для начала давайте установим Windows 10 IoT Core на Raspberry Pi. Для этого нам потребуется Windows 10 IoT Core Dashboard, который можно взять вот здесь. Там же можно при желании скачать отдельно ISO-образ, но особого смысла в этом нет — инструмент сделает это за вас.

См. также: «Что действительно случилось с Vista: инсайдерская ретроспектива»

Я обычно пищу о вещах, которыми непосредственно занимался — или писал код, или управлял проектом. В этой статье я выбрал другой подход, чтобы написать о своём взгляде на глубинные причины фиаско Windows Vista (кодовое название Longhorn). Хотя это случилось более десяти лет назад, то был ключевой период по переходу на мобильные устройства — и те события вызвали долговременные последствия внутри Microsoft. Я нашёл, что многие попытки описать проблемы Microsoft, особенно в связи с переходом на мобильную платформу, неубедительны и не совпадают с моим пониманием того, что случилось. Статья в Vanity Fair «Потерянное десятилетие Microsoft» описывает бюрократическую гниль и подковёрную борьбу («жизнь… стала непрерывно жестокой») или культурную гниль из-за негативных последствий системы оценки рейтинга конкурентных стеков. Последующая статья в The Atlantic описывает ситуацию как классическую «дилемму инноватора».

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

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

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

Для работы с жестким диском его для начала необходимо как-то разметить, чтобы операционная система могла понять в какие области диска можно записывать информацию. Поскольку жесткие диски имеют большой объем, их пространство обычно разбивают на несколько частей — разделов диска. Каждому такому разделу может быть присвоена своя буква логического диска (для систем семейства Windows) и работать с ним можно, как будто это независимый диск в системе.

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

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


Давайте вместе в этом разберемся.

Часть 3. Попытка подведения итогов

[Предыдущий раздел]

Я люблю сравнивать эти две картинки:



Слева — «Пейзаж Марса в районе полярной шапки» кисти советского художника-фантаста Георгия Курнина. Предположительно 1960-х годов, достоверно не позже 1974-го. Справа — работа то ли Xinhua/Reuters Photo, то ли NASA, выполненная в 2008-м году, незадолго до посадки станции Феникс на Марс. Изображающая, как ни странно, тоже полярные районы Марса.

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

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

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

Часть 1. pT-диаграмма

Часть 2. Прогулка

→ Первая часть

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

В этом разделе не будет большой глубины. А будет небольшая экскурсия по окраинам pT-диаграммы, редко посещаемым даже популяризаторами науки. Зачем? Чтобы показать, что богатство миров и явлений, скорее всего, отнюдь не убывает при удалении от привычного нам «центра мира условий». И что, наверное, в тех местах может происходить что-то интересное и сюжетообразующее… при условии, что хоть один профессиональный писатель сможет качественно это помыслить. Но это — отдельная тема для обсуждения в третьей части. Здесь же у нас будут просто далёкие миры. Не в парсеках далёкие, но оттого не менее труднодостижимые.

Юпитер

Вот так он выглядит снаружи: