Михаил Овчинников

Macbook Pro 2017

Девайсы

Мой Mac mini служит верой и правдой уже 6 лет, за это время у меня не возникало особых претензий к его производительности, я лишь увеличил размер оперативной памяти до 8 Гб и поменял винчестер на SSD. Несмотря на маленькие размеры, мобильным его не назовешь: нужно таскать с собой монитор, мышку и клавиатуру, поэтому периодически я задумывался о покупке макбука. Окончательным решением в пользу замены компьютера стал анонс macOS Mojave, где было сказано, что отныне поддерживаются только модели начиная с mid-2012 (из-за необходимости наличия видеокарты, совместимой с технологией Metal).

Изначально я рассматривал к покупке модели 2015 года: привычные разъемы и отсутствие проблем с клавиатурой при сопоставимом по качеству железе (и яблочко светится!). На момент написания поста, было реально достать только 15-дюймовую модель, но и это оказалось не так просто: в нескольких магазинах столкнулся с одной и той же ситуацией: заказываешь на сайте (где он якобы в наличии), тебе перезванивает менеджер и говорит: «Мы такую модель больше не возим, хотите подберем аналогичную 2017 года?». Так как я всё равно хотел 13-дюймовую модель, то решил не заниматься ретроградством и приобрел конфигурацию без тачбара с i7 2,5 ГГц, 16 ГБ RAM и 128 ГБ SSD.

Общие впечатления

Комплект как всегда минимален: устройство и зарядка. Провод зарядного устройства в этой модели отсоединяемый, что хорошо: будет легко поменять, если перетрётся. Кабель с двух сторон имеет Type C разъем — удобно, не перепутаешь какой стороной вставлять и несложно искать замену.

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

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

Делая «революционный» шаг с избавлением от мини-джека, они положили в коробку переходник (хотя это и не так нужно), здесь же фактически лишая пользователей прямого доступа к миллионам выпущеных устройств с традиционными USB-разъемами, к мониторам с HDMI, к картам памяти и прочим радостям жизни, нам не дают ответа как с этим жить. Мы всегда ценили компанию за сильную экосистему, но сейчас и она даёт трещины.

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

Клавиатура и тачпад

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

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

За тачпад хочется просто обнять инженеров Apple, хоть где-то они смогли сделать все правильно: огромная поверхность, отличная чувствительность, Force Touch (постоянно использую для предпросмотра ссылок в Safari), ни разу даже не возникало мысли подключить мышку.

Быстродействие

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

Методику измерения придумал не я, а Эш Фюрроу (иногда кажется, что какая бы мысль тебе в голову не пришла, до тебя это уже сделали ребята из Artsy), он изложил её у себя на гитхабе, где заодно и собирает статистику по времени сборки. Суть проста: берем проект Eidolon и засекаем время от нажатия кнопки Run до появления основного экрана приложения (хочу заметить, не сплэш-скрина, а именно первого настоящего экрана приложения). Повторяем это для сборки с нуля и для ребилда. Eidolon — это вполне enterprise-grade приложение с крупной кодовой базой и большим количеством зависимостей, поэтому время, затраченное на его сборку, будет весьма показательно.

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

sudo gem install bundler
xcode-select —install

git clone https://github.com/artsy/eidolon.git
cd eidolon
bundle install
bundle exec fastlane oss

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

Модель Процессор Оперативная память Хранилище Версия Xcode
Mac mini (Mid 2011) 2,5 GHz Intel Core i5 8GB 1333MHz DDR3 256GB SSD 9.4.1
iMac (Retina 5K, 27-inch, 2017) 3,4 GHz Intel Core i5 16GB 2400 MHz DDR4 1TB Fusion Drive 9.3.1
MacBook Pro (13-inch, 2017) 2,5 GHz Intel Core i7 16GB 2133 MHz LPDDR3 128GB SSD 9.4.1

На всех компьютерах стоит High Sierra последней версии. Для тестов был запущен только Xcode, все остальные приложения закрыты. В режиме «холодного старта» симулятор был закрыт, т.е. учитывается время которое требуется на его загрузку. Перед стартом сборки я каждый раз дожидался когда закончится процессинг файлов, так как он вносит слишком большую погрешность в измерения.

Результаты я замерял в секундах и записал в текстовый файл в следующем виде:

#                           Fresh   Incremental
"Mac Mini (mid 2011)"       203     19
"iMac (2017)"               170     23
"MacBook Pro (mid 2017)"    94      10

Чтобы получить график, прогоняем результат через Gnuplot со следующим кодом:

set terminal png size 800,500
set output 'output.png'

red = "#f44336"; 
blue = "#3F51B5";

set style data histogram
set style histogram cluster gap 1
set style fill solid
set boxwidth 0.9

set xtics format ""

set grid ytics
set ylabel "Build time, sec." rotate by 90

plot "data.dat" using 2:xtic(1) title "Fresh Build" linecolor rgb red, \
            '' using 3 title "Incremental Build" linecolor rgb blue

Таким образом, получается что на чистый билд у Mac mini уходит больше 3,5 минут, iMac справляется чуть меньше чем за 3 минуты, а герою сегодняшнего обзора потребовалось всего лишь 1,5 минуты. Результат получился интересным: то что новый ноутбук в 2 раза опережает мой старенький mini меня не удивило, а вот то, что iMac показал такие слабые результаты, вызывает недоумение. Тут конечно много факторов, которые могли повлиять: чуть более старая версия Xcode, Fusion Drive, который все-таки медленнее чем SSD, но все равно это слишком сильное отклонение.

Автономность

Не скажу за всю Одессу, но в моем режиме использования (Xcode, VS Code, Safari, SourceTree, Zeplin, Telegram), ноутбук спокойно держится рабочий день и к вечеру остается процентов 20 заряда. Зарядку с собой я обычно не беру — знаю что хватит. Хотя думаю, если бы я пользовался Chrome, Slack и ещё какими-нибудь приложениями на Electron, то заряд уходил бы гораздо быстрее, но все равно такая автономность не может не радовать.

P.S.

Я устал настраивать каждый раз с нуля свои маки, поэтому взял скрипт laptop от Thoughtbot и адаптировал его под свои нужды, он лежит у меня на GitHub под названием workstation. Делал на скорую руку, чтобы быстро засетапить ноутбук после покупки, потом буду постепенно дорабатывать, если будете использовать, то не стесняйтесь писать в issues и слать pull-request.

Как найти путь к домашней директории симулятора iOS

Разработка под iOS Xcode

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

Самый быстрый путь: воспользоваться командой po в консоли LLDB. Для этого ставим выполнение приложения “на паузу”.

В появившейся командной строке LLDB пишем:

po NSHomeDirectory()

В ответ нам вернется путь к домашней директории симулятора, теперь его можно скопировать и открыть в Finder (Cmd+Shift+G). Файлы, которые вы туда положите будут сразу видны в приложении, перезапуск не потребуется.

Источник

Скрываем и показываем иконку приложения в Dock на macOS

Разработка под macOS Swift

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

В общем случае для этого даже не требуется писать код: достаточно выставить соотвествующий флаг в Info.plist.

 <key>LSUIElement</key>
 <true/>

По-человечески этот ключ называется “Application is agent (UIElement)” и собственно он переведет приложение в режим агента, в котором иконка в доке показываться не будет.

Если же поведение твоего приложения ещё более специфично и есть желание управлять отображением иконки в доке в процессе работы, то можно воспользоваться методом setActivationPolicy класса NSApplication.

Чтобы скрыть иконку (по сути этот метод аналогичен выставлению флага в Info.plist):

 NSApp.setActivationPolicy(.accessory)

Вернуть назад приложение в нормальный режим:

 NSApp.setActivationPolicy(.regular)

Показываем индикатор загрузки файла в Finder

Разработка под macOS Swift

Ты наверное замечал, что при загрузке файлов, например в Chrome, в Finder рядом с файлом показывается некий круговой индикатор загрузки.

Отображение индикактора загрузки файла в Finder

Для этого используется специальный атрибут файла com.apple.progress.fractionCompleted, а также есть небольшая (но неочевидная) хитрость: нужно выставить дату создания файла равной 1984-01-24 08:00:00 +0000 а соотвественно, чтобы скрыть индикатор вернуть файлу актуальную дату и убрать атрибут.

Метод на Swift будет выглядеть следующим образом:

func setProgress(value: Double, forFile path: String) throws {
    var fileAttributes = try FileManager.default.attributesOfItem(atPath: path)
    let extendedAttributesKey = FileAttributeKey(rawValue: "NSFileExtendedAttributes")
    var extendedAttributes = fileAttributes[extendedAttributesKey] as? Dictionary ?? [:]
    let progressData = "\(value)".data(using: .ascii)
    extendedAttributes["com.apple.progress.fractionCompleted"] = progressData
    fileAttributes[extendedAttributesKey] = extendedAttributes

    let dateString = "1984-01-24 08:00:00 +0000"
    let dateFormatter = DateFormatter()
    dateFormatter.dateFormat = "YYYY-MM-dd HH:mm:ss Z"
    let date = dateFormatter.date(from: dateString)
    fileAttributes[FileAttributeKey.creationDate] = date

    try FileManager.default.setAttributes(fileAttributes, ofItemAtPath: path)
}

Пример использования:

try! setProgress(value: 0.6, forFile: "/Users/michael/1.txt")

Скачать пример

Программное добавление папки в «Избранное» в Finder

Разработка под macOS Swift Objective-C

Возникла специфическая задача: добавить программно папку в раздел «Избранное» на боковой панели Finder в macOS. Эта и другая подобная информация хранится в *.sfl файлах, в ~/Library/Application Support/com.apple.sharedfilelist/. Работать с ними напрямую не получится, для этого существует системная утилита sfltool.

Через терминал выполняем следующую команду:

/usr/bin/sfltool add-item com.apple.LSSharedFileList.FavoriteItems file:///Users/$USER/Desktop/

Если нужно произвести такую операцию непосредственно из кода программы, то придется работать с API LSSharedFileList, которое объявлено Apple устаревшим, при этом альтернативных способов сделать это компания не предложила. Применяя этот метод, следует также помнить, что он не будет работать в sandbox-режиме.

На Objective-C:

- (void)appendFavoriteItemWithURL:(NSString *)itemPath {
    NSURL *url = [NSURL fileURLWithPath:itemPath];
    LSSharedFileListRef list = LSSharedFileListCreate(NULL, kLSSharedFileListFavoriteItems, NULL);
    if (list) {
        LSSharedFileListItemRef item = LSSharedFileListInsertItemURL(list,
                                                                    kLSSharedFileListItemLast,
                                                                    NULL,
                                                                    NULL,
                                                                    (__bridge CFURLRef)url,
                                                                    NULL,
                                                                    NULL);
        if (item) {
            CFRelease(item);
        }

        CFRelease(list);
    }
}

Пример использования:

NSString * itemPath = [@"~/Documents/src" stringByExpandingTildeInPath];
[self appendFavoriteItemWithURL:itemPath];

На Swift:

func appendFavoriteItemWithURL(itemPath: String) {
    let url = NSURL(fileURLWithPath: itemPath) as CFURL
    let list = LSSharedFileListCreate(nil,
                                    kLSSharedFileListFavoriteItems.takeRetainedValue(),
                                    nil).takeRetainedValue()
    let startPosition: LSSharedFileListItem = kLSSharedFileListItemBeforeFirst.takeRetainedValue()

    LSSharedFileListInsertItemURL(list,
                                startPosition,
                                nil,
                                nil,
                                url,
                                nil,
                                nil)
}

Пример использования:

let itemPath = NSString(string: "~/Documents/src").expandingTildeInPath
appendFavoriteItemWithURL(itemPath: itemPath)

Источники

Установка и использование языка Swift на Ubuntu 16.04

Swift Linux

Некоторое время язык Swift был доступен только для операционной системы OS X, в составе среды разработки Xcode, но недавно на официальном сайте стали доступны сборки и для последних версий Ubuntu. Практической пользы от такого шага не очень много: большинство библиотек так и не были портированы, и разрабатывать для iOS на альтернативных платформах всё еще невозможно. Хотя существует призрачная возможность писать серверный код на том же языке, что и код приложения, но пока инструментарий развит слабо, использование языка от Apple на Ubuntu будет представлять скорее академический интерес. С другой стороны, доступного функционала хватит, чтобы изучить основы языка и писать несложные консольные утилиты, не приобретая дорогостоящие устройства, что может оказаться для многих плюсом.

Установка

Для удобства все действия будем производить в терминале. В стандартной версии Ubuntu его можно открыть сочетанием клавиш ctrl + alt + t.

Cкачаем последнюю стабильную версию Swift с официального сайта:

wget https://swift.org/builds/swift-3.1.1-release/ubuntu1604/swift-3.1.1-RELEASE/swift-3.1.1-RELEASE-ubuntu16.04.tar.gz

Распакуем скачанный архив:

tar xvf swift-3.1.1-RELEASE-ubuntu16.04.tar.gz

Поместим содержимое архива в директорию /opt:

mv swift-3.1.1-RELEASE-ubuntu16.04 /opt/swift

Добавим директорию с исполняемыми файлами в переменную окружения PATH:

echo 'export PATH=/opt/swift/usr/bin:$PATH' >>~/.profile

Выполним команду source, чтобы обновить переменную PATH для текущей сессии:

source ~/.profile

Для работы Swift потребуется clang, установим эту зависимость:

sudo apt-get update
sudo apt-get install clang

На этом установка закончена, теперь можно проверить текщую версию языка командой:

swift --version

В ответ команда должна вернуть текущую версию языка и платформу.

REPL

Запустить интерактивную консоль Swift (REPL — Read Eval Print Loop) можно одноименной командой: swift. В ней можно начать изучение синтаксиса языка, подробнее о её возможностях можно прочитать на сайте Apple. Выйти из REPL можно командой :exit.

Hello world

Напишем и скомпилируем простейший пример, который будет выводить надпись «Hello, Swift». Создайте файл hello.swift, и введите следующий код:

print("Hello, Swift")

Сохраним файл и скомпилируем его командой:

swiftc hello.swift

Теперь выполним его:

./hello

В ответ ожидаемо получим строку «Hello, Swift».

Swift build

Создайте директорию с названием проекта, например Hello. Перейдите в неё и выполните:

swift package init --type executable

Эта команда сгенерирует базовую структуру проекта. Код, который должен выполняться находится в Sources/main.swift, по-умолчанию там написано print("Hello, world!").

Соберем проект командой:

swift build

Результат компиляции будет находиться по следующему пути: .build/debug/Hello (относительно корня проекта). Запустив его, получим тот же результат, что и в предыдущем примере.

Принудительное обновление provisioning profile в Xcode 8.3

Xcode Code signing

После обновления в Xсode 8.3 исчезло окно управления provisioning profile проекта. Им было удобно пользоваться для принудительного удаления и скачивания профайлов. Например, когда добавляешь на Developer Portal новые устройства для ad-hoc установки, профайл в Xcode обновляется далеко не сразу и не всегда. Чтобы решить эту проблему, можно было зайти в настройки аккаунта, открыть окно управления профайлами и сертификатами, нажать правой кнопкой мыши на профайле, выбрать «Move to trash», после чего заново скачивался новый.

Сейчас такой возможности нет из-за того, что в Xcode 8 ввели Automatic provisioning, и видимо в Apple сочли, что такая возможность больше не требуется. Проблема же с тем, что профайл не всегда обновляется после внесения изменений на Developer Portal осталась.

Существует очень простое решение: нужно зайти в директорию /Users/michail/Library/MobileDevice/Provisioning\ Profiles (это Library, которая в домашней папке, нужно включить отображение скрытых файлов чтобы её увидеть) и удалить нужные профайлы, или всё содержимое, Xcode потом автоматически загрузит свежие профайлы.

Статический анализ кода при помощи SwiftLint

SwiftLint Swift Статический анализатор Xcode

SwiftLint — это статический анализатор Swift-кода, разработанный компанией Realm, который проверяет его на соответствие стилю и соглашениям принятым в сообществе разработчиков. Главным образом он базируется на Swift style guide от Github. Почему это важно? Наличие соглашений и стандартов всегда лучше их отсутствия: код написанный в едином стиле, проще читать при командной разработке, а также косвенно анализаторы кода способны улучшить и стабильность приложения, так как распознают заведомо плохие практики. Начинающим изучать Swift разбор ошибок и предупреждений анализатора поможет разобраться в особенностях языка, а также избежать использования устаревших конструкций, которые могли быть скопированы с сайтов вроде Stack Overflow.

Установка

SwiftLint является консольным приложением и устанавливается через Homebrew, поэтому достаточно ввести команду:

brew install swiftlint

Инструмент можно использовать отдельно, запуская команду swiftlint в консоли, что не очень удобно, поэтому существует довольно простой способ интегрировать его с Xcode.

Интеграция с Xcode

Откройте проект, который вы разрабатываете, зайдите в его настройки, на вкладку Build Phases и добавьте новую фазу сборки с запуском скрипта.

Добавление новой фазы сборки в Xcode

В появившемся поле для ввода нужно добавить следующий код:

if which swiftlint >/dev/null; then
    swiftlint autocorrect
    swiftlint
else
    echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

Команда swiftlint autocorrect автоматически исправляет простые недочеты вроде пустых строк с пробелами и т.п. Я всегда запускаю ее перед проверкой, чтобы не отвлекаться на тривиальные вещи. Данный скрипт будет выполняться при каждой сборке проекта, а все ошибки и предупреждения будут выводиться наряду со стандартными предупреждениями Xcode.

Настройка правил

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

disabled_rules:
  - line_length

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

Управляем сторонними библиотеками с CocoaPods

Разработка под iOS Разработка под macOS CocoaPods Менеджер пакетов Xcode

CocoaPods — менеджер пакетов, сделанный по образу и подобию RubyGems, позволяющий легко скачивать и подключать сторонние библиотеки к Swift и Objective-C проектам.

Установка CocoaPods

Менеджер пакетов написан на Ruby и распространяется через RubyGems. В общем случае установка сводится к единственной команде в терминале:

sudo gem install cocoapods --pre

Процесс может занять некоторое (продолжительное) время, не выводя ничего на экран, стоит быть к этому готовым и не прерывать установку до завершения (должна появиться надпись вроде «xx gems installed»).

Далее установим мастер-репозиторий CocoaPods со спецификациями всех доступных проектов. Делается это командой в терминале:

pod setup --verbose

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

Установка и использование библиотек

Чтобы сразу продемонстрировать все возможности создадим новый Swift-проект и установим для него Objective-C компонент под названием BEMCheckBox.

Откроем Xcode и создадим самый простой Single View, Swift-проект, я назову его «CocoaPodsExample». Сохраните его в любое место, закройте Xcode, откройте терминал, перейдите в директорию с проектом и напишите:

pod init

В корне директории должен появиться новый файл: Podfile. Это обычный текстовый файл с конфигурационным кодом на Ruby, в котором мы должны указать требуемые библиотеки. Обычно все солидные opensource-проекты указывают в Readme, что именно нужно прописать в Podfile для установки, и BEMCheckBox здесь не исключение. Откройте его любым текстовым редактором и приведите к следующему виду:

platform :ios, "9.0"

target 'CocoaPodsTest'do
  use_frameworks!

  pod 'BEMCheckBox'
end

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

Иногда требуется установить не оригинальную библиотеку, а наиболее акутальный форк от другого автора (например, исправление критичного бага, который ещё не успели смерджить) в таком случае можно использовать следующий синтаксис:

pod 'SWRevealViewController', :git => 'git@github.com:safarijv/SWRevealViewController.git', :branch => 'safarijv-additions'

В данном случае мы указываем репозиторий и ветку из которой нужно взять под. Если не указать ветку, то по-умолчанию будет браться master. Аналогично нужно поступать, если вам требуется внести свои изменения в библиотеку: создать форк, закоммитить изменения и сослаться на свой репозиторий в Podfile. Не стоит делать изменения в уже установленных подах, т.к. потом будет очень сложно разобраться (особенно другим разработчикам), почему поведение библиотеки отличается от описанного в оригинальной документации.

Далее запускаем установку командой:

pod install

После окончания установки, в директории с проектом должен появиться файл *.xcworkspace, который объединяет созданный нами проект и проект Pods со всеми необходимыми библиотеками и конфигурационными файлами. Теперь для работы с проектом нужно открывать именно воркспейс, а не сам проект (в противном случае ему не будут видны сторонние библиотеки).

Проверить, что библиотека подключилась легко: перейдите на Storyboard, поместите на ViewController UIView из Object Library и в Identity Inspector поставьте ему класс BEMCheckBox (если не получается, то можно попробовать собрать проект Cmd + B). Запустите проект, и у вас должен появиться работающий чекбокс. Обратите внимание, что мы подключили Objective-C библиотеку к Swift проекту, если вы делали это раньше вручную, то помните, что для этой цели нужно было создавать специальный заголовочный файл Objective-C Bridging Header, но последние версии CocoaPods генерируют его автоматически, поэтому в этом больше нет необходимости.

CocoaPods и системы контроля версий

Обычно хорошим тоном в современной разработке является не добавлять сторонние библиотеки под контроль версий. Однако авторы проекта наоборот, рекомендуют хранить директорию Pods/ вместе с проектом. Преимуществом такого подхода является переносимость проекта и отсутствие зависимости от внешних инфраструктур (например Github, где хранится большинство исходных кодов библиотек). С другой стороны, в крупном проекте со множеством библиотек это может существенно увеличить размер репозитория, а в случае командной разработки добавит головной боли при слиянии веток. Поэтому в небольших проектах, где вы являетесь единственным разработчиком, можно смело оставить директорию Pods/ под контролем версий, а в крупных проектах и при командной разработке, лучше добавить ее в .gitignore.

Исправляем неработающий под Linux тачпад на Asus X550LN

Linux Ubuntu Asus X550LN Тачпад

Примечание от 28.05.2017: Начиная с версии Ubuntu 16.04 проблему с тачпадом наконец-то починили, но тем не менее этот пост всё ещё остаётся актуальным для многих дистрибутивов.

Уже почти год моим основным компьютером является ноутбук Asus X550LN. За это время я неоднократно менял на нем операционные системы, даже пытался жить на Windows, но все время возвращался к излюбленным мной Debian-based дистрибутивам Linux. К сожалению, в 2015 году проблемы с поддержкой аппаратного обеспечения под альтернативными ОС никак не заканчиваются. Так, практически на всех испробованных мной дистрибутивах, не работает тачпад. Проблема проявляется следующим образом: при касании тачпада, в зависимости от дистрибутива, либо не происходит ничего, либо курсор двигается, но невозможно совершить клик, либо же система намертво зависает.

Багтрекер Red Hat рапортует об успешном решении проблемы, в то время как под Ubuntu (и Debian) до сих пор нет полноценного решения. Существует лишь обходной путь с включением тачпада в режиме эмуляции ps/2 мыши (что означает отсутствие мультитача и других продвинутых функций). Его мы и рассмотрим.

При установке системы подключаем и используем внешнюю USB-мышь, тачпад, во избежание проблем, не трогаем.

Для включения режима эмуляции, необходимо добавить параметр загрузки ядра, для чего нужно отредактировать файл /etc/default/grub.

sudo nano /etc/default/grub

Далее находим параметр GRUB_CMDLINE_LINUX_DEFAULT и после quiet splash через пробел добавляем psmouse.proto=bare, сохраняем файл и выходим из редактора.

После выполняем:

sudo update-grub

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

1 of 3 Туда →