macOS *

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

• назначать иконку приложения в строке меню
• делать приложение размещенным только в строке меню
• добавлять пользовательское меню
• показывать всплывающее по запросу пользователя окно и прятать его, когда необходимо, используя Event Monitoring

Замечание: это руководство предполагает, что вы знакомы со Swift и macOS.

Интерполяция строк была в Swift с ранних версий, но в Swift 5.0 этот функционал был расширен, стал быстрее и значительно мощнее.

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

Swift 5.0 стал доступен с выходом Xcode 10.2, но работа над следующей версией продолжается и уже есть известия о том, чего в ней можно ждать.

Ключевая особенность Swift 5.1 — модульная стабильность (module stability), которая позволяет нам использовать сторонние библиотеки, не волнуясь о том, при помощи какой версии компилятора Swift они были созданы. Похоже на ABI stability, которую мы получили в Swift 5.0, но есть небольшая разница: ABI stability разрешает различия в версиях Swift на этапе выполнения, а module stability — на этапе компиляции.

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

Swift 5 — долгожданный релиз, включающий в себя несколько десятков улучшений и исправлений. Но самой главной целью релиза Swift 5.0 было достижение ABI стабильности. В этой статье вы узнаете, что такое ABI и что стабильный ABI даст iOS/macOS разработчикам. А также проведём разбор нескольких новых фич Swift 5.

Рассуждения о выдыхающемся рынке смартфонов на фоне падающих продаж имеют под собой некоторые основания: судя по всему, современная эра смартфонов, начатая iPhone и на развитии заложенного в него потенциала идей построенная, подходит к концу. Но это не конец эпохи в полном смысле слова, а лишь назревающий эволюционный переход в цепочке телефон → мобильный телефон → смартфон → смарт(?). Скорее всего, на следующем этапе это будет уже никакой не «фон», и огромное количество специфических и неотъемлемых на сегодняшний день могут оказаться вынесены за его пределы (как, например, память) или просто настолько измениться (как, например, способы ввода и вывода), что оперировать привычными сейчас категориями вроде дисплея нет смысла. За вычетом всех возможных «переменных», в попытке оставить только самый минимум необходимого, у меня получилось 4 условия: Портативное Персональное Коммуникационное Вычислительное Устройство. Но важнее тут не то, что обеспечит связность поколений, сколько то, что даст этому устройству новое качество, которое и позволит говорить о следующем этапе эволюции.

И одна из самых перспективных и оформленных идей «нового качества», отлично вписывающаяся в эти четыре параметра — это, на самом деле, давно и хорошо известная идея запихнуть полную функциональность мощного ПК в форм-фактор смартфона. Плюс этого варианта в том, что его ценность довольно очевидна, в отличие от движения по пути AR или VR-мутации, которое добавляет необходимую дополнительную неизвестную — создание некой VR или AR-фичи, которая станет абсолютным must have, оправдывающим развитие, сфокусированное на реализации её возможностей.

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

Предыдущая запись: «Куда расти смартфонам».

Как Spotify может помочь в изучении демонов, RFC, сетей и продвижении опенсорса. Или что бывает, если заплатить не получается, а некоторые премиумные плюшки очень хочется.

Джозеф Райт, «Пленный» — иллюстрация «сильного» захвата

Список «захваченных» значений находится перед списком параметров замыкания и может «захватить» значения из области видимости тремя разными способами: используя ссылки «strong», «weak» или «unowned». Мы часто его используем, главным образом для того, чтобы избежать циклов сильных ссылок («strong reference cycles» aka «retain cycles»).
Начинающему разработчику бывает сложно принять решение, какой именно применить способ, так что вы можете потратить много времени, выбирая между «strong» и «weak» или между «weak» и «unowned», но, со временем, вы поймёте, что правильный выбор — только один.

Сегодня использование цифровых сертификатов X509 v.3 стало обыденным делом. Все больше людей используют их для доступа на сайт Госуслуги, ФНС, электронные торги и т.д. И все больше людей хотят знать, что же находится в этом «сундуке» под названием сертификат. И если сертификат является аналогом паспорта, то как его можно прочитать/просмотреть. Да, в операционных системах присутствуют различные утилиты для просмотра. Но рядовому гражданину они мало что дадут. Возьмем для примера утилиту gcr-viewer, которая, по сути, является стандартным средством для просмотра в Linux-системах, а значит и в отечественных ОС:

AudioKit — это аудиофреймворк, разработанный аудиоинженерами, программистами и музыкантами специально для iOS и OSX. Он предоставляет инструменты для обработки и синтезирования звука. Под капотом — это смесь из Swift, Objective-C, C++ и С, и Audio Unit API от Apple. Потрясающие (и довольно сложные) технологии завёрнуты в очень дружелюбное Swift API, к которому можно обращаться прямо из Xcode Playgrounds!

В этом туториале мы отправимся в путешествие по AudioKit, а заодно и истории синтезирования звука. Вы узнаете об основах физики звука и том, как работали первые синтезаторы, такие как Hammond Organ. Также будут рассмотрены и современные техники, например, семплинг.

Приготовьте ваш любимый напиток, устраивайтесь поудобнее и вперёд!

Предыстория

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

Хочу вам рассказать о том, как мы пришли к Electron как технологии для написания нашего приложения.

*Ссылка на библиотеку и демо видео в конце статьи. Для понимания того, что происходит, и кто все эти люди, рекомендую прочитать предыдущую статью.

В прошлой статье мы ознакомились с подходом, позволяющим осуществлять "горячую" перезагрузку c++ кода. "Код" в данном случае — это функции, данные и их согласованная работа друг с другом. С функциями особых проблем нет, перенаправляем поток выполнения из старой функции в новую, и все работает. Проблема возникает с данными (статическими и глобальными переменными), а именно со стратегией их синхронизации в старом и новом коде. В первой реализации эта стратегия была очень топорной: просто копируем значения всех статических переменных из старого кода в новый, чтобы новый код, ссылаясь на новые переменные, работал со значениями из старого кода. Конечно это некорректно, и сегодня мы попытаемся исправить этот изъян, попутно решив ряд небольших, но интересных задач.

В статье опущены детали, касающиеся механической работы, например чтение символов и релокаций из elf и mach-o файлов. Упор делается на тонких моментах, с которыми я столкнулся в процессе реализации, и которые могут быть полезны кому-то, кто, как и я недавно, ищет ответы.

Привет!

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

Вот что удалось выяснить.

* Ссылка на библиотеку в конце статьи. В самой статье изложены механизмы, реализованные в библиотеке, со средней детализацией. Реализация для macOS еще не закончена, но она мало чем отличается от реализации для Linux. Здесь в основном рассматривается реализация для Linux.

Гуляя по гитхабу одним субботним днем, я наткнулся на библиотеку, реализующую обновление c++ кода налету для windows. Сам я слез с windows несколько лет назад, ни капли не пожалел, и сейчас все программирование происходит либо на Linux (дома), либо на macOS (на работе). Немного погуглив, я обнаружил, что подход из библиотеки выше достаточно популярен, и msvc использует ту же технику для функции "Edit and continue" в Visual Studio. Проблема лишь в том, что я не нашел ни одной реализации под не-windows (плохо искал?). На вопрос автору библиотеки выше, будет ли он делать порт под другие платформы, ответ был отрицательный.

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

"Как так?" — подумал я, и принялся раскуривать фимиам.

Digest MBLT DEV — еженедельная подборка новостей из мира iOS-разработки. Каждую пятницу доставляем прямо в почту полезные материалы с комментариями от топовых iOS-разработчиков. Вот уже 200 выпусков = 200 недель.

Первый номер дайджеста выпущен командой e-Legion в 2015 году. С тех пор появились новые рубрики и авторы, да и количество подписчиков растёт каждую неделю. Если вы ещё не читаете наш iOS-дайджест, то мы искренне не понимаем, почему. Пора это исправить.

SwiftOnSecurity пишет на тему недавнего перехода на Chromium в качестве встроенного в Windows движка рендеринга:

Это не только про Chrome, это также про ElectronJS. Microsoft думает, что EdgeHTML не может достичь полного паритета по функциональности с Chromium, чтобы заменить его в приложениях Electron. Дублирование движка Electron в каждой программе становится значительной проблемой производительности. Вместо этого они хотят иметь один на всех экземпляр Electron вместе со своими дополнениями.

Electron это рак, убивающий и macOS, и Windows по мере распространения. Microsoft должна предложить ему замену с нативными оптимизациями, чтобы улучшить производительность и использование ресурсов.

Я не совсем разделяю их пессимизм по поводу нативных приложений, но Electron – это, без сомнений, бич платформы. Я думаю, что Mac окажет большее сопротивление, чем Windows, потому что платформа Mac привлекает большее число неравнодушных людей. Но тем не менее, я беспокоюсь.

Некоторое время назад (осенью 2016), при разработке очередной версии технологической платформы 1С:Предприятие внутри команды разработки встал вопрос о поддержке нового стандарта C++14 в нашем коде. Переход на новый стандарт, как мы предполагали, позволил бы нам писать многие вещи элегантней, проще и надежней, упрощал поддержку и сопровождение кода. И в переводе вроде бы нет ничего экстраординарного, если бы не масштабы кодовой базы и специфические особенности нашего кода.

Для тех кто не знает, 1С:Предприятие – это среда для быстрой разработки кросс-платформенных бизнес-приложений и runtime для их выполнения в разных ОС и СУБД. В общих чертах в состав продукта входят:

• Кластер серверов приложений, работает на Windows и Linux
• Клиент, работающий с сервером по http(s) или по собственному бинарному протоколу, работает на Windows, Linux, macOS
• Веб-клиент, работающий в браузерах Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari (написан на JavaScript)
• Среда разработки (Конфигуратор), работает на Windows, Linux, macOS
• Инструменты администрирования серверов приложений, работают на Windows, Linux, macOS
• Мобильный клиент, подключающийся к серверу по http(s), работает на мобильных устройствах под управлением Android, iOS, Windows
• Мобильная платформа — фреймворк для создания оффлайновых мобильных приложений с возможностью синхронизации, работающих на Android, iOS, Windows
• Среда разработки 1C:Enterprise Development Tools, написана на Java
• Сервер Системы Взаимодействия

Мы стараемся по максимуму писать один код для разных ОС — кодовая база сервера общая на 99%, клиента — примерно на 95%. Технологическая платформа 1С:Предприятие преимущественно написана на C++ и ниже приведены приблизительные характеристики кода:

• 10 миллионов строк С++ кода,
• 14 тысяч файлов,
• 60 тысяч классов,
• полмиллиона методов.

И все это хозяйство надо было перевести на C++14. О том, как мы это делали и с чем столкнулись в процессе, мы сегодня и расскажем.

Доброго времени суток, дорогие товарищи!

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

Как-то раз, мне пришлось призадуматься над одной небольшой задачкой. Есть компьютер iMac, есть успешно установленная OS X Sierra на внешний, подключенный через USB SSD-диск, и есть странное, удивительное, и при этом — полное, отсутствие файла подкачки.

Представляю вашему вниманию перевод моей статьи из блога Проекта Darling. Маленькая справка по используемым понятиям: Darwin – операционная система с открытым исходным кодом, лежащая в основе macOS, iOS и других ОС от Apple; Mach-O – бинарный формат исполняемых файлов и библиотек, использующийся в Darwin; dyld – динамический загрузчик, использующийся в Darwin для загрузки файлов Mach-O; dylib – динамически загружаемая библиотека (обычно имеет расширение .dylib).

Цель Проекта Darling – сделать возможным запуск macOS-приложений под Linux, и умение загружать бинарные файлы в формате Mach-O – один из ключевых шагов к достижению этой цели.

Исходно, Darling был выстроен вокруг собственной реализации загрузчика Mach-O и идеи транслирования вызовов между высокоуровневым Darwin API и его Linux-аналогами. С тех пор наш фокус сместился на запуск кода во всё более и более изолированном Darwin-контейнере. С тех пор как мы перешли на использование Mach-O для внутренних компонентов Darling, у нас появилась возможность использовать исходный dyld от Apple, а также собирать многие другие компоненты Darwin с открытым исходным кодом. Нам всё ещё нужен простой загрузчик Mach-O, чтобы загружать сам dyld.

Среди новичков бытует мнение, что популярность языка программирования можно определить по количеству выпущенных книг. В качестве примера можно упомянуть Java или Python – и отчасти это будет правдой. Но есть языки, которые в бумажных книгах не особо-то и нуждаются. Просто из-за своей молодости и того факта, что официальный tutorial отвечает абсолютно на все вопросы начинающего программиста.



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

Поэтому автор блога GeekBrains Илья Бубнов вдоль и поперёк изучил российские издательства, чтобы отыскать 5 самых популярных книг по Swift, выпущенных в олдскульном формате.

Вот оно какое наше лето. Треть мы потеряли уже где-то. Что же делать? Дай мне, друг, совета. Отдыхайте с огоньком. Ля, ля, ля, ля, ля, ля. Ля, ля, ля, ля, ля, ля.

В Джире на доске как на опушке, тасков так, что не видать макушку, горы эстимейтов, плачь в подушку. Голова идёт кругом. Ля, ля, ля, ля, ля, ля. Ля, ля, ля, ля, ля, ля.

Интро к 176-му выпуску Digest MBLT DEV от Саши Чёрного прекрасно, как и сам дайджест, который вместе с Сашей каждую пятницу готовят Руслан Гуменный, Александр Зимин и Иван Козлов.

Если вы ещё не читаете наш iOS-дайджест, то мы искренне не понимаем, почему. Пора это исправить.