Я лично продавал когда-то iMac свой. У него была проблема — копоть на обратной стороне экрана. Я самостоятельно вскрывал и чистил. Процедура не из приятных. И потом еще несколько битых пикселей обнаружились… Не факт, что Б/У iMac не пройдет через такие же пытки. Mac Mini в этом плане — самый надежный вариант из Б/У. Там особо ничего не поломаешь, не зальешь клавиатуру (как в случае с MacBook), не попортишь экран (как в случает с iMac, MacBook).
Неплохо бы увидеть пример iMac, который вы рекомендуете. Возможно читатель заинтересуется именно вашим предложением, но без конкретики (сравнения процессоров, например) будет сложно выбрать достойный моноблок.
Точно. Я тоже не сразу решил в какой ресурс стоит запостить эту публикацию. Попробую объяснить, почему решил постить именно в Хабр.
Итак, тема возникла только из-за того, что Swift заставляет разработчиков предпринимать определенные шаги для ускорения сборки проектов. Не было бы проблемы — не появилась бы публикация. Я на себе ощутил все сложности при работе с большими проектами на медленной машине и достаточно продолжительное время искал различные пути решения возникшей проблемы.
Данной публикацией я делюсь своим опытом с другими IT-специалистами, занимающимися разработкой приложений для техники Apple. Возможно, они сделают какие-то выводы и тем самым смогут улучшить свои профессиональные навыки.
Столкнулся бы гик/энтузиаст/фанат/пользователь техники Apple с данной проблемой вне IT-сферы, вне разработки приложений для техники Apple? Будет ли такому человеку интересна скорость сборки Swift проекта? Сомневаюсь…
На основании этих доводов и был выбран Хабр. Но если вы не согласны и сомневаетесь — пожалуйста, поделитесь своими мыслями! Это поможет мне в следующий раз более точно выбрать ресурс для размещения публикации.
После всех случаев починки зарядного устройства, у меня сложилось впечатление, что в один прекрасный момент у меня не получится его починить. Вот одна из последних фотографий его состояния. Похоже на "доживающее"?
Я вот буквально вчера смотрел спецификации MacBook 13” 2017 года и процессор там был указан 2-х ядерный. Именно этот ноутбук я имел ввиду, когда употреблял слово «свежий». Поправьте меня, если этот ноутбук не «свежий» или не 2-х ядерный.
Возможно, но написать надо было. Если бы я прочитал подобное перед покупкой MacBook 13’’ три года назад — не купил бы ноут. Может эта публикация поможет кому-то не совершить ошибку. Ну а вообще «минус» — отличный инструмент показать что статье не место на хабре.
Вот как раз ради начинающих разработчиков я и не пишу полную инструкцию к действиям. Я не хочу чтобы люди не задумываясь делали все по шаблону (как это делал я когда-то). Мне кажется, что лучше всего когда человек сам доходит до конца, даже если пройти ему надо лишь последнюю ступень. Это шаг помогает осознать не только как применять, но и почему подход получился именно таким.
Накатать самому — хорошая позиция. Я ее сам придерживаюсь! Ведь гораздо легче понять материал если его попробовать использовать. Примеры кода в спойлерах в конце публикации не достаточно убедительны? (:
Попробовал ваш подход. Идея понравилась, но… допустим я хочу применить для какого-то лейбла UIViewStyle<UIView> и UIViewStyle<UILabel>. И у меня это не заработало. Вот пример, на который жалуется компилятор:
var style1: UIViewStyle<UIView>!
var style2: UIViewStyle<UILabel>!
var style3: UIViewStyle = .compose(style1, style2)
Поэтому, я предполагаю, что вы объединяли между собой только стили одного типа. Хотя, использование typealias, который вы привели в начале публикации, мог бы справиться с задачей совмещения стилей класса и стилей родителей класса.
typealias UIViewStyle<T: UIView> = (T)-> Void
В итоге у меня получилось использовать стили вот таким образом:
let view = UILabel()
view.decorator[UIView.backgroundColor(), UILabel.textSubtitle()]
return view
Где стили, например, обернуты в static функции класса:
Неплохо бы увидеть пример iMac, который вы рекомендуете. Возможно читатель заинтересуется именно вашим предложением, но без конкретики (сравнения процессоров, например) будет сложно выбрать достойный моноблок.
Итак, тема возникла только из-за того, что Swift заставляет разработчиков предпринимать определенные шаги для ускорения сборки проектов. Не было бы проблемы — не появилась бы публикация. Я на себе ощутил все сложности при работе с большими проектами на медленной машине и достаточно продолжительное время искал различные пути решения возникшей проблемы.
Данной публикацией я делюсь своим опытом с другими IT-специалистами, занимающимися разработкой приложений для техники Apple. Возможно, они сделают какие-то выводы и тем самым смогут улучшить свои профессиональные навыки.
Столкнулся бы гик/энтузиаст/фанат/пользователь техники Apple с данной проблемой вне IT-сферы, вне разработки приложений для техники Apple? Будет ли такому человеку интересна скорость сборки Swift проекта? Сомневаюсь…
На основании этих доводов и был выбран Хабр. Но если вы не согласны и сомневаетесь — пожалуйста, поделитесь своими мыслями! Это поможет мне в следующий раз более точно выбрать ресурс для размещения публикации.
После всех случаев починки зарядного устройства, у меня сложилось впечатление, что в один прекрасный момент у меня не получится его починить. Вот одна из последних фотографий его состояния. Похоже на "доживающее"?
… но живу далековато от Москвы/Лондона и на оффлайн собеседование прилетать очень накладно. Вот такой вариант бы описали (:
Поэтому, я предполагаю, что вы объединяли между собой только стили одного типа. Хотя, использование typealias, который вы привели в начале публикации, мог бы справиться с задачей совмещения стилей класса и стилей родителей класса.
В итоге у меня получилось использовать стили вот таким образом:
Где стили, например, обернуты в static функции класса: