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

Вот почему мы создали Figma, командный инструмент работы над дизайном интерфейсов, как облачный сервис, распространяемый в виде веб-приложения.

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

Дорога к результату была очень непроста; в итоге, мы практически создали браузер внутри браузера.

Отрасль разработки программного обеспечения развивается молниеносными темпами. На рынок постоянно выходят новые технологии, инструменты и “маст-хэв” продукты, заставляя программистов ежегодно обновлять свой арсенал. Каким бы эффективным ни был язык программирования или фреймворк, рано или поздно возникает что-то еще более быстрое и мощное. Создавая продукты для разработчиков, мы в JetBrains стараемся угнаться за этим разнообразием, не упуская из виду главное — насколько инструмент разработки удобен в использовании.

Прошлой зимой мы объявили, что работаем над новой средой программирования на основе платформы IntelliJ — для языка Go. До недавнего времени эта IDE была известна под кодовым названием Gogland (в честь острова Гогланд в Финском заливе, в 180 км к западу от Санкт-Петербурга), но в качестве окончательного названия был выбран GoLand.

Сегодня мы, наконец, выпустили официальную версию GoLand 2017.3. Предлагаем вам скачать ее, и если понравится, купить!

Если вы уже используете IntelliJ IDEA Ultimate, то все возможности GoLand можете пользоваться прямо в ней, просто установив этот плагин.

Пост основан на статье medium.com/@RobertGummesson/regarding-swift-build-time-optimizations-fc92cdd91e31 + небольшие изменения/дополнения, то есть текст идет от моего лица, не третьего.

Всем знакома ситуация после изменения файла(ов) или просто переоткрытия проекта:






Нужно сказать, что какой-то особой проблемы с компиляцией я не замечал когда писал на Objective-C, но всё изменилось с приходом в массы swift. Я частично отвечал за CI сервер по сборке iOS проектов. Так вот, проекты на swift собирались невыносимо медленно. Еще разработчики любят тащить поды (cocoapods зависимости) на каждый чих в свои swift проекты, иногда, в безумном количестве. Так вот, компиляция всей этой смеси могла продолжаться несколько минут, хотя сам проект состоял буквально из пары десятков классов. Ну ладно, как бы ясно, язык новый, на этапе компиляции происходит намного больше проверок, чем в том же ObjC, глупо ожидать, что она будет работать быстрее (да, swift это строго типизированный язык и всё должно быть максимально явно объявлено (как в Java, например), в отличии от ObjC, где не всё так строго). Разработчики swift с каждым релизом обещают в x раз ускорения скорости компиляции. Ну вроде, действительно, сборка 2.0 и уже потом 2.2 стала работать быстрее, вот вот на носу уже 3.0 версия (конец года).

Компилятор компилятором, но оказывается, что время сборки проекта можно катастрофически увеличить буквально несколькими строчками кода. Часть примеров взято из вышеупомянутой статьи, часть самописные (не поверил автору и хотелось самому проверить). Время замерял через

time swiftc -Onone file.swift

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

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

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

Хотя Discord — это приложение для голосового и текстового чата, каждый день через него проходит более ста миллионов изображений. Конечно, мы бы хотели, чтобы задача была простой: просто перенаправить картинки вашим друзьям по всем каналам. Но в реальности доставка этих изображений создаёт довольно большие технические проблемы. Прямая ссылка на картинки выдаст хосту с картинкой IP-адреса пользователей, а большие изображения расходуют много трафика. Чтобы избежать этих проблем, требуется промежуточный сервис, который будет получать изображения для пользователей и изменять их размер для экономии трафика.

Встречайте Image Proxy

Для выполнения этой работы мы создали сервис Python и креативно назвали его Image Proxy. Он загружает картинки с удалённых URL, а затем выполняет ресурсоёмкую задачу по ресайзингу с помощью пакета pillow-simd. Этот пакет работает удивительно быстро, используя где только возможно для ускорения ресайзинга инструкции x86 SSE. Image Proxy будет получать HTTP-запрос, содержащий URL, чтобы загрузить, изменить размер и, наконец, выдать окончательное изображение.

Здравствуйте. Сегодня речь пойдёт про Conan — современный менеджер зависимостей для C/C++. Если Вы уже активно работаете с ним, то навряд ли найдёте что-нибудь новое для себя. Иначе — прошу под кат.

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

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

С момента появления биткойн-блокчейн пережил множество хардфорков. Часть из них не приобрела популярности по тем или иным причинам (недостаток поддержки, баги в ПО), например Bitcoin Unlimited, Bitcoin Classic, Bitcoin XT.

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

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

Привет!

Продолжаем говорить про Haskell со спикерами FPConf 2017.

Павел Аргентов задал несколько вопросов Senior Software Engeneer в Tweag I/O Александру Вершилову, программисту, который уже 10 лет продвигает Haskell в индустрии.

Команда Rust рада сообщить о двух новых версиях Rust: 1.22.0 и 1.22.1. Rust — это системный язык программирования, нацеленный на безопасность, скорость и параллельное выполнение кода.

Подождите, две версии? В последний момент мы обнаружили проблему с новой macOS High Sierra в версии 1.22.0 и по разным причинам выпустили версию 1.22.0 как обычно, но так же выпустили 1.22.1 с исправлением. Ошибка была найдена в менеджере пакетов Cargo, а не в rustc, и затронула только пользователей macOS High Sierra.

Если у вас установлена предыдущая версия Rust, для обновления достаточно выполнить:

$ rustup update stable

Если же у вас еще не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта. С подробными примечаниями к выпуску Rust 1.22.0 и 1.22.1 можно ознакомиться на GitHub.

Что вошло в стабильную версии 1.22.0 и 1.22.1

Самое главное изменение в этой версии, которого многие долго ждали: теперь вы можете использовать ? с Option<T>! Около года назад, в Rust 1.13, мы ввели оператор ? для работы с Result<T, E>. С тех пор ведутся дискуссии о том, как далеко оператор ? должен зайти: Должен ли он остаться только для Result? Разрешать ли пользователям расширять его? Должен ли он использоваться с Option<T>?

В Rust 1.22, основное использование оператора ? с Option<T> стабилизировано. Теперь такой код соберется:

Ardour пока является самым крупным из музыкальных проектов, участвующих в обзоре дефектов кода. Проект включает около 1000 файлов исходного кода на языке C++. Проект активно поддерживается сообществом разработчиков, при этом я не нашёл упоминаний об использовании каких-либо инструментов статического анализа. Как следствие — множество ошибок разного характера. В статье будут описаны самые интересные из них.

Мы продолжаем развивать Exonum. В этот раз мы сосредоточили внимание на двух вещах: полностью перевели хранение данных на RocksDB, при этом прекратив поддержку LevelDB, и переписали сетевой код на Tokio. Зачем: эти решения позволили нам повысить эффективность хранения данных и увеличили производительность кода в сети.

О переходе с LevelDB на RocksDB мы говорили в статье о релизе прошлой версии фреймворка. Поэтому в сегодняшнем анонсе хотим подробнее остановиться на изменениях, которые пришли с Tokio, рассказать, как мы реализовали асинхронную обработку событий, и отметить другие улучшения.

Из центральной части Канады — на юго-запад США! Альбукерке расположен в штате Нью-Мексико:



На встрече международного комитета по стандартизации C++, которая прошла в этом городе, приняли одно очень большое нововведение в С++20 и несколько маленьких.

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

Этот раз не стал исключением и я задумал создать бота, который позволял бы с наибольшим комфортом и минимумом усилий смотреть любимые фильмы и сериалы, да еще и предоставлял контент в нескольких вариантах озвучки. Сказано — сделано. И теперь, когда железный друг человека радостно раздает пользователям их любимые шоу, я бы хотел поговорить о том, что сопутствовало созданию бота, какие проблемы вставали на моем пути и как они были решены. В первой главе я расскажу о Go глазами PHP-разработчика, во второй главе о поиске дзена для парсинга Кинопоиска, а в третьей — о недокументированной фиче Telegraph.

Здравствуйте, уважаемые читатели!

Жизнь не стоит на месте, и вот в «O'Reilly» задумались об издании первой фундаментальной книги о языке программирования Rust:



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

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

Про микросервисы не рассказывал только ленивый. Вот и мы не ленивые. Решили поговорить о микросервисах. Но только не ещё раз о том, что это такое, а о том, как мы их сервируем в 2ГИС. Например, наши бекенды держат 15 млн пользователей в месяц. На встрече поговорим о деплое, координации и согласованности данных.

Привет!

Начинаем публиковать разговоры со спикерами FPConf 2017. Павел Аргентов расспросил самого зажигательного евангелиста ФП и Haskell Дениса Шевченко.



В начале разговора — расскажи немного о себе.

Меня зовут Денис Шевченко. Я основатель сообщества ruHaskell. В данный момент тружусь Haskell-разработчиком в компании IOHK. Бывший С++-разработчик, ныне Хаскелист, начинающий ФП-евангелист и автор незаконченной книги “Haskell по-человечески”.

Научное сообщество практически незнакомо со статическим анализатором кода PVS-Studio. 30 ноября и 1 декабря состоится мероприятие «Технологии анализа, моделирования и трансформации программ» в рамках открытой конференции ИСП РАН им. В.П. Иванникова. Я уверен, что это одно из самых тематичных для нас мероприятий, где новая аудитория могла бы узнать о существовании и возможностях анализатора PVS-Studio. На мой взгляд, наиболее подходящим для этого мог стать доклад, касающийся поиска ошибок в операционной системе Tizen. К сожалению, доклад получил отрицательные отзывы рецензентов и не будет включен в программу конференции. Тем не менее, пользуясь случаем, подведу итоги наших исследований, касающихся кода Tizen.

Model-Updater-View — функциональный паттерн, успешно применяемый в языке Elm в основном для разработки пользовательских интерфейсов. Что бы им воспользоваться надо создать тип Model, представляющий полное состояние программы, тип Message, описывающий события внешней среды, на которые программа должна реагировать, меняя свое состояние, функцию updater, которая из старого состояния и сообщения создает новое состояние прораммы и функции view, которая вычисляет по состоянию программы требуемые воздействия на внешнюю среду, которые порождают события типа Message. Паттерн очень удобный, но у него есть маленький недостаток — он не позволяет описать какие события имеют смысл для конкретных состояний программы.

Схожая проблема возникает (и решается) и при использовании ОО-паттерна State.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи Don't use lambdas as listeners in Kotlin автора Alex Gherschon

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