I don't know iOS-specific links off-hand - I'm basically just referring to rudimentary state-driven UI. But implemented manually, without a framework, and therefore bug-prone for unfamiliar devs.
For example (this is pseudo-code, I haven't written Swift in a long time):
class ProfileViewController: UIViewController {
struct State: Hashable {
var username: String?
var profileImageURL: String?
}
var state = State() {
didSet {
if state != oldValue { updateView() }
}
}
// must be idempotent
// must only read state and only mutate the view
function updateView() {
usernameLabel.text = state.username
profileImageView.setImage(url: state.profileImageURL)
}
}
Lots of stuff can complicate this: External sources of truth (CoreData, UserDefaults), reference types (no memberwise equality), self-mutating views (UITextField), continuously changing values that state is derived from (the current time). But the pattern is so simple it's easy to extend it to account for these things as needed, usually with another layer of `update...()`, e.g. `updateState()` from a CoreData observer.
Scorm is a zip file with html files to structure content any way you want with a minimal amount of mandatory standards.
It was never meant for assessment, nor is it secure. The creator of scorm said to not use it learning had to be secured.
It’s not a system or a framework in any meaningful or standardized sense, and more of a format for compiling content that can be copied between different places.
I just took the conceptualization of it away from the sufficient experience I have with LMS to do the same with it:
Learning management systems are rarely about learning. Too often, they're first about about managing learning for the learning manager, and teh priorities of the learning manager (maintaining compliance) and that's what the software and sales process aims for.
The learner, actually learning, or being a central focus is a second or third class citizen in such tools.
Yep. Literally every EdTech idea is a rehashing of the same flawed reasoning: we just need better monitoring and metrics to manage everyone’s learning process! No. Learning comes from repetitive deliberate practice in the zone of proximal development. For essentially all knowledge-based skills, what’s missing is the core foundational skill progression that leads to actual mastery.
How many different personal training styles do you see for competitive sports? There’s variation, but only at the margins. Nobody deviates from the essential training core because doing so leads to poor performance and competitive failure. And yet we have a total free-for-all in knowledge disciplines where we just throw untrained PhDs in front of a classroom and assume they’ll produce results. Oh, and we also provide zero tangible incentives for them to improve learning outcomes.
How to teach, and how to learn, and how to learn how to learn are for sure different things.
With post secondaries, one thing I see is the obsession with pedagogy, which makes sense on one hand, where teachers who teach K-12, learn how to teach children, for the unfamiliar - peda is children, and gogy roughly means "how to lead".
If our teaching is rooted actually or inaccurately using a word that is rooted in a practice of how to lead children, it doesn't surprise me that the learning experiences of non-adults, including young adults, are so hard.
I've got to work in K-12, Academia and Industry training/certification, and where they work, they do not share as much as each of the categories would like to think.
Thus, when someone takes a K-12 framework or approach and applies it in industry, it's feasible that it might not work, but the takes on why seem to get ignored.
Fundamentally skills and the ability to use your skills change and evolve and fixes curriculum that takes 1-3 years to change one sentence doesn't really work in more and more places. This is more a fundamental change than a short lived irritant.
> The diagram below shows the rule: within each business domain (e.g. App Settings), code can only depend “forward” through a fixed set of layers (Types → Config → Repo → Service → Runtime → UI). Cross-cutting concerns (auth, connectors, telemetry, feature flags) enter through a single explicit interface: Providers. Anything else is disallowed and enforced mechanically.
Can anyone give me a simplified explanation of what they’re saying here? Having some trouble understanding.
They're describing a layered architecture enforced by some script in CI.
For example, if you had a `backend`, `common`, and `frontend` package, you would be OK having backend/frontend depending on common, but you wouldn't want common depending on backend/frontend or backend/frontend depending on each other.
If you think about JavaScript, there is nothing stopping your dependency graph from becoming spaghetti. It sounds like they built static analysis to enforce rules.
Some languages have this built in like Java (Project Jigsaw), Go, and Rust. JavaScript, Python, etc. have no such feature.
It's really nothing special -- it has existed before. It just becomes a _lot_ more important with agents since they produce a lot of code, and it is good to have lots of static analysis when heavily utilizing agents.
They mention this in the article:
> This is the kind of architecture you usually postpone until you have hundreds of engineers. With coding agents, it’s an early prerequisite: the constraints are what allows speed without decay or architectural drift.
