Я лично продавал когда-то 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 функции класса:
Прочитайте свой изначальный пост. Там явно указано про комментарии и решения. Я, между прочим, с вами сразу согласился на тему того, что комментарии неактуальные и поставил под сомнение лишь слово решения и привел довод, где описанное в публикации решение будет работать. И после того, как я вами согласился на тему неактуальности комментариев автора, вы опять упрекнули меня за игнорирование комментариев.
1. Может вы что-то другое имели ввиду под словом решения?
2. Может вы думали, что я ваши комментарии назвал неактуальными?
Неплохо бы увидеть пример iMac, который вы рекомендуете. Возможно читатель заинтересуется именно вашим предложением, но без конкретики (сравнения процессоров, например) будет сложно выбрать достойный моноблок.
Итак, тема возникла только из-за того, что Swift заставляет разработчиков предпринимать определенные шаги для ускорения сборки проектов. Не было бы проблемы — не появилась бы публикация. Я на себе ощутил все сложности при работе с большими проектами на медленной машине и достаточно продолжительное время искал различные пути решения возникшей проблемы.
Данной публикацией я делюсь своим опытом с другими IT-специалистами, занимающимися разработкой приложений для техники Apple. Возможно, они сделают какие-то выводы и тем самым смогут улучшить свои профессиональные навыки.
Столкнулся бы гик/энтузиаст/фанат/пользователь техники Apple с данной проблемой вне IT-сферы, вне разработки приложений для техники Apple? Будет ли такому человеку интересна скорость сборки Swift проекта? Сомневаюсь…
На основании этих доводов и был выбран Хабр. Но если вы не согласны и сомневаетесь — пожалуйста, поделитесь своими мыслями! Это поможет мне в следующий раз более точно выбрать ресурс для размещения публикации.
После всех случаев починки зарядного устройства, у меня сложилось впечатление, что в один прекрасный момент у меня не получится его починить. Вот одна из последних фотографий его состояния. Похоже на "доживающее"?
Поэтому, я предполагаю, что вы объединяли между собой только стили одного типа. Хотя, использование typealias, который вы привели в начале публикации, мог бы справиться с задачей совмещения стилей класса и стилей родителей класса.
В итоге у меня получилось использовать стили вот таким образом:
Где стили, например, обернуты в static функции класса:
Вы использовали анимированное применение стилей? Поделитесь примером?
1. Может вы что-то другое имели ввиду под словом решения?
2. Может вы думали, что я ваши комментарии назвал неактуальными?