Что тут еще сказать, браво! Согласен на все 100%. 17 лет назад когда я вышел на работу джавистом, не было погони за лычками синьора, не было толерантности к плохому коду, к стремным решениям, никого не уговаривали пользоваться мозгами вместо задницы, боясь нарушить тонких чувств и никто не умер.
Именно так. Любой код, который уже написан одним программистом, для другого будет легаси. Увы, код - это побочный эффект выполнения задачи и в наши дни имеет свойство устаревать через неделю после коммита. И как побочный эффект он создает ряд других проблем уже не связанных с исходной целью: сопровождение, латание дыр, обновление зависимостей и тд и тп. Например, вы написали лучший код в жизни, но через время пакет, от которого он зависит перестал поддерживаться, или код который от него зависит ушел вперед и ваш пакет надо обновить. Тот кто это сделает назовет его легаси. Поэтому это так.
Здорово, что вы пишите доку и тесты. Это делает ваше легаси поддерживаемым )
С каких пор Легаси это какой-то плохо структурированный или недокументированный код, полный техдолга?
Легаси - буквально, наследие. Не видел еще разработчика который обожает копаться в коде, что написали до него, который ему надо поддерживать, и не чертыхается на каждом слове. Ты хоть каждую строку задокументируй, следующий разраб будет недоволен. Просто разница в подходах, мироощущении, опыте. С научной точки зрения, это нюансы нейропластичности, где попытка осознать чужой ход мышления заставляет мозг изменять старые нейронные связи и создавать новые отчего возникает дискомфорт и трение.
Никакой связи у понятия «Легаси» с качественными характеристиками кода нет.
Эта чудесная стопка с разделами банковского приложения в свёрнутом виде. Не разворачивается. Не могу доступиться ни как карте, ни к вкладу, ни к баллам плюса. Пада-пара-пам!
И написать некуда. Напишу сюда, а то гении яндекса без обратной связи, так и будут думать что они гении.
Два с половиной миллиона DAU это конечно недостаточное кол-во. Ладно, рад бы подискутировать, да вы все равно эту статью писали для маркетинга, отвечаете общими фразами и цитатами из документации - кпд такой дискуссии ниже нуля.
Чёт какой-то бессвязный компот. Тут тебе и запуск сторибордов (кого-нибудь ещё интересует жизненный цикл сторибордов?). Тут и метрикКит, которым если автор пользовалась, то знала что органайзере хрен дождешься данных от него. В трёх строках смешались Pods и SPM. Heif как формат данных зачем-то вплели, никто и никогда не будет его использовать для ресурсов, общих с вебом или андроидом. Статья ради статьи. Если б не интернет, который всё стерпит, было б жалко бумагу
Претензий действительно нет, статью дальше заголовка не читал. Просто уточил мотивацию неуместного использования таких фундаментальных понятий. Спора никакого нет. Удачи!
Браузер и веб-страницы, отсылаемые с сервера в виде html и css тоже backend-driven UI. Мы же не называем это паттерном. Для этой задачи миллион решений, что противоречит понятию паттерна как регулярного шаблона для решения конкретной задачи конкретным образом.
Скажу, не холивара ради, а как размышления о развитии Computer Science, корутины не пришли на замену реактивности, Pub-Sub как таковой не накладывает требований к инфраструктуре выполнения асинхронного кода. Observation прямо сейчас выглядит как шаг назад в сторону императивных API в эпоху декларативного мейнстрима типа SwiftUI и Jetpack Compose. Крокодил withObservationTracking вынуждает писать код полный сайд эффектов, его «одноразовость», рекурсивный вызов самого себя для длительного во времени наблюдения изменений, выглядит жутким костылем, решением уже решенных проблем худшим, с точки зрения computer science, способом. Что думаете на этот счет?
Спасибо за статью, коллега! В SwiftData почти все хорошо кроме требуемого таргета ? и встроенного Observation. Эппл как бы намекает - юзайте модели прямо во вьюхах. И это совсем не то, чего ждешь от полноценного фреймворка. В многослойной и почти чистой архитектуре это вынуждает либо поднимать модели нарушая границы абстракции, либо создавать стейт между слоями для observability. Или может я чего не так понял?.. жаль что концепция наблюдаемых объектов так быстро сменила движок с комбайна на нечто третье…
Вызов был принят ) Собственно наскоро запилил примерчик.
Выглядит вот так:
Код не претендует на перфенционизм автора, но реализован через хедер секции. А если еще и с напильником, чтобы краюшки скруглить где надо...
enum Constants {
static let scrollViewCoordinateSpace = "ScrollView"
static let itemHeight: CGFloat = 40
}
struct ContentView: View {
enum ScrollDirection {
case idle
case up
case down
}
@State private var selectedItemIndex: Int? = .none
@State private var selectedItemOffset = CGFloat.zero
@State private var scrollDirection: ScrollDirection = .idle
var offsetFactor: CGFloat {
switch scrollDirection {
case .idle, .down: 0
case .up: Constants.itemHeight
}
}
var body: some View {
NavigationStack {
ScrollView {
LazyVStack(pinnedViews: [.sectionHeaders]) {
Section {
ForEach(1...100, id: \.self) { count in
itemView(for: count)
.background(GeometryReader { proxy in
if selectedItemIndex == count {
Color.clear.preference(
key: ViewOffsetKey.self,
value: proxy.frame(in: .named(Constants.scrollViewCoordinateSpace)).minY
)
}
})
}
} header: {
selectedPinnedView
}
}
.padding()
.onPreferenceChange(ViewOffsetKey.self) {
if selectedItemOffset < $0 {
scrollDirection = .up
} else {
scrollDirection = .down
}
if selectedItemOffset <= -UIScreen.main.bounds.height
&& $0 < selectedItemOffset { return }
self.selectedItemOffset = $0
}
}
.coordinateSpace(name: Constants.scrollViewCoordinateSpace)
.navigationTitle("SelectedPinnedView")
.navigationBarTitleDisplayMode(.inline)
}
}
func itemView(for index: Int) -> some View {
Button(action: {
selectedItemIndex = index
}) {
Text("Item \(index)")
.foregroundStyle(.white)
.frame(height: Constants.itemHeight)
.frame(maxWidth: .infinity)
.background(selectedItemIndex == index ? .green : .gray)
.clipShape(RoundedRectangle(cornerRadius: 8))
.contentShape(RoundedRectangle(cornerRadius: 8))
}
.buttonStyle(.plain)
}
@ViewBuilder
var selectedPinnedView: some View {
if let selectedItemIndex, selectedItemOffset < 0 + offsetFactor {
itemView(for: selectedItemIndex)
}
}
}
ЗЫ.: Отредактировал onPreferenceChange, заметил, что LazyVStack убирает View когда она выходит за 1 высоту экрана, отчего offset выставлялся в 0. Но теперь все гладко и шелковисто.
Если вы ориентируетесь на b2b продажи, то форма распространения выбрана не самая удачная. Софт для кодеров по идее должен стоить по разному для персонального и корпоративного использования. На данный момент, вариант анализа логов как у автора статьи видится более функциональным решением для использования в компании, а ваш именно для персонального использования, никакая компания не будет платить ни цента за лицензию которую нельзя передать.
Вот тут у меня вопрос, если вы знаете за Composable Architecture, зачем Swinject тащить в качестве DI? Вам дали вполне ясные лучшие практики внедрения зависимостей через Environment. Почему бы не воспользоваться им?
Что тут еще сказать, браво! Согласен на все 100%. 17 лет назад когда я вышел на работу джавистом, не было погони за лычками синьора, не было толерантности к плохому коду, к стремным решениям, никого не уговаривали пользоваться мозгами вместо задницы, боясь нарушить тонких чувств и никто не умер.
Именно так. Любой код, который уже написан одним программистом, для другого будет легаси. Увы, код - это побочный эффект выполнения задачи и в наши дни имеет свойство устаревать через неделю после коммита. И как побочный эффект он создает ряд других проблем уже не связанных с исходной целью: сопровождение, латание дыр, обновление зависимостей и тд и тп. Например, вы написали лучший код в жизни, но через время пакет, от которого он зависит перестал поддерживаться, или код который от него зависит ушел вперед и ваш пакет надо обновить. Тот кто это сделает назовет его легаси. Поэтому это так.
Здорово, что вы пишите доку и тесты. Это делает ваше легаси поддерживаемым )
С каких пор Легаси это какой-то плохо структурированный или недокументированный код, полный техдолга?
Легаси - буквально, наследие. Не видел еще разработчика который обожает копаться в коде, что написали до него, который ему надо поддерживать, и не чертыхается на каждом слове. Ты хоть каждую строку задокументируй, следующий разраб будет недоволен. Просто разница в подходах, мироощущении, опыте. С научной точки зрения, это нюансы нейропластичности, где попытка осознать чужой ход мышления заставляет мозг изменять старые нейронные связи и создавать новые отчего возникает дискомфорт и трение.
Никакой связи у понятия «Легаси» с качественными характеристиками кода нет.
Немного про BDUI из Яндекса:
Эта чудесная стопка с разделами банковского приложения в свёрнутом виде. Не разворачивается. Не могу доступиться ни как карте, ни к вкладу, ни к баллам плюса. Пада-пара-пам!
И написать некуда. Напишу сюда, а то гении яндекса без обратной связи, так и будут думать что они гении.
Пошли хвалебные обзоры прошлогоднего планшета - скоро анонс следующего поколения )) складские остатки старого сами себя не продадут )
Два с половиной миллиона DAU это конечно недостаточное кол-во. Ладно, рад бы подискутировать, да вы все равно эту статью писали для маркетинга, отвечаете общими фразами и цитатами из документации - кпд такой дискуссии ниже нуля.
Чёт какой-то бессвязный компот. Тут тебе и запуск сторибордов (кого-нибудь ещё интересует жизненный цикл сторибордов?). Тут и метрикКит, которым если автор пользовалась, то знала что органайзере хрен дождешься данных от него. В трёх строках смешались Pods и SPM. Heif как формат данных зачем-то вплели, никто и никогда не будет его использовать для ресурсов, общих с вебом или андроидом. Статья ради статьи. Если б не интернет, который всё стерпит, было б жалко бумагу
Претензий действительно нет, статью дальше заголовка не читал. Просто уточил мотивацию неуместного использования таких фундаментальных понятий. Спора никакого нет. Удачи!
Браузер и веб-страницы, отсылаемые с сервера в виде html и css тоже backend-driven UI. Мы же не называем это паттерном. Для этой задачи миллион решений, что противоречит понятию паттерна как регулярного шаблона для решения конкретной задачи конкретным образом.
А почему backed-driven UI это паттерн? Крупновато для паттерна, не находите?
Скажу, не холивара ради, а как размышления о развитии Computer Science, корутины не пришли на замену реактивности, Pub-Sub как таковой не накладывает требований к инфраструктуре выполнения асинхронного кода. Observation прямо сейчас выглядит как шаг назад в сторону императивных API в эпоху декларативного мейнстрима типа SwiftUI и Jetpack Compose. Крокодил
withObservationTracking
вынуждает писать код полный сайд эффектов, его «одноразовость», рекурсивный вызов самого себя для длительного во времени наблюдения изменений, выглядит жутким костылем, решением уже решенных проблем худшим, с точки зрения computer science, способом. Что думаете на этот счет?Спасибо за статью, коллега! В SwiftData почти все хорошо кроме требуемого таргета ? и встроенного Observation. Эппл как бы намекает - юзайте модели прямо во вьюхах. И это совсем не то, чего ждешь от полноценного фреймворка. В многослойной и почти чистой архитектуре это вынуждает либо поднимать модели нарушая границы абстракции, либо создавать стейт между слоями для observability. Или может я чего не так понял?.. жаль что концепция наблюдаемых объектов так быстро сменила движок с комбайна на нечто третье…
И вам спасибо за статью! Пишите еще!
Вызов был принят ) Собственно наскоро запилил примерчик.
Выглядит вот так:
Код не претендует на перфенционизм автора, но реализован через хедер секции. А если еще и с напильником, чтобы краюшки скруглить где надо...
ЗЫ.: Отредактировал
onPreferenceChange
, заметил, чтоLazyVStack
убираетView
когда она выходит за 1 высоту экрана, отчего offset выставлялся в 0. Но теперь все гладко и шелковисто.Идея неплохая, но почему бы не использовать
LazyVStack
сpinnedViews
? илирелигиятаргет не позволяет? :)Таки МИР работает для оплаты в AppStore, надо только подождать когда все перейдут, а все перейдут ибо вариантов нет.
Обязательно включите в курс лекцию по релокации
Если вы ориентируетесь на b2b продажи, то форма распространения выбрана не самая удачная. Софт для кодеров по идее должен стоить по разному для персонального и корпоративного использования. На данный момент, вариант анализа логов как у автора статьи видится более функциональным решением для использования в компании, а ваш именно для персонального использования, никакая компания не будет платить ни цента за лицензию которую нельзя передать.
Вот тут у меня вопрос, если вы знаете за Composable Architecture, зачем Swinject тащить в качестве DI? Вам дали вполне ясные лучшие практики внедрения зависимостей через Environment. Почему бы не воспользоваться им?
пощади отец, чего ж так дорого-то )