I have been doing web development for last 1 year. Can someone recommend a resource to learn Architecture?
Do Not Learn Frameworks – Learn the Architecture
61–70 of 86 posts
Re: Do Not Learn Frameworks – Learn the Architecture
#62The author is only partway through the learning process. There is a circular progression. The total newbie just "learns the framework" and is helpless to debug through leaking abstractions. I agree 100% that you don't want to be stuck there. So eventually she decides to just compose her own architecture. Now she understands all the pieces. But as she matures further as a programmer and architect, she starts to see al…
It's not intimidation, it's just determining which path you want to take. The people who constructed the ground of the popular frameworks had to start somewhere too.
Re: Do Not Learn Frameworks – Learn the Architecture
#63TLDR; You start out as a noobie, you get better and learn from your mistakes.
Re: Do Not Learn Frameworks – Learn the Architecture
#64Earlier quoted context omitted.
> I eventually realized that our super small team and I simply couldn't sustain keeping this super-custom framework maintained and updated, not with all the other work that needs to be done at the company. We moved most of our work to Haskell's Yesod framework, which has years of community work and incredible craftsmanship behind it. And then Haskell's Yesod gets abandoned when the core devs move to shinier things an…
In the case where an open source framework loses its maintainer, in the worst case you are the maintainer. In that case you are no worse off than with your own framework, except that for a number of years the maintenance work was done for you for free.
With one small difference: you'll likely have a much larger attack surface because the third party framework was created to do much more than to just service your applications.
And all that code will need to be maintained now. That can get very costly.
Re: Do Not Learn Frameworks – Learn the Architecture
#65I think patterns are stupid idea. You bother learning a way of doing things (the pattern ), and you bother all you colleagues learning that way of doing things. OK, cool, that sounds good. But you never bother to teach it the computer! The computer should understand the pattern as well, in form of some abstraction. Because now you force yourself and others to recognize pattern every time you need to use it (either re…
Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated" in his 1996 book Patterns of Software [1]. To summarize as briefly as possible: abstraction has costs, too. Sometimes it's better to spell out the pattern. As you probably know, the idea of patterns came from architecture, where "reusable abstraction" translates to "modular house" – which is not obviously better. [1]: https:/…
> Richard P. Gabriel critiqued this notion of "patterns should be abstracted and instantiated"
I think patterns should always be "abstracted and instantiated". I always found his example of actual code in support of his argument a bit weird. From the book:
Does the following code fragment:
(mismatch sequence list :from-end t
:start1 20 :start2 40
:end1 120 :end2 140 :test #’baz)
seem easier to understand than this pattern of use:
(let ((subseq1 (reverse (subseq sequence 20 120)))
(subseq2 (reverse (subseq list 40 140))))
(flet ((the-same (x y) (baz x y)))
(loop for index upfrom 0
as item1 in subseq1
as item2 in subseq2
finally (return t) do
(unless (the-same item1 item2)
(return index)))))
:test #'baz
Re: Do Not Learn Frameworks – Learn the Architecture
#66This blog slows to a crawl on a 4 core phone with 3 GB of RAM.
Something about not using javascript heavy frameworks for a site that displays articles.
Re: Do Not Learn Frameworks – Learn the Architecture
#67Earlier quoted context omitted.
The difference is that the framework is built to be an open source framework - it has general abstractions. Your own patterns and practices are developed to apply directly to what you're building.
But a good framework has well chosen abstractions that took many person-hours to settle upon, a community of engineers working to perfect it, and probably uncountable hours of production battle-testedness.
I'm not sure that time and bodies necessarily produce good abstractions.
Re: Do Not Learn Frameworks – Learn the Architecture
#68The biggest counterpoint that I can think of to actually putting your own framework into production, especially if it's a one man/woman show, is security. A large open source framework will have implemented and fixed a ton of security blunders which you will not have. It doesn't really matter how encyclopedic your knowledge of software architectural patterns is, even though design is important for system security, there is a large component that is case-by-case attack mitigation. Your almost always going to be better off with a security conscious framework than with an ad-hoc framework.
Another way to look at it is that every production framework needs a subset of its development team that is really knowledgeable and paranoid about security, proactively watches for new attacks, and which can very quickly roll out effective mitigations. If you don't have at least one person on your team that will handle this role, then you're better off using a security conscious framework, and if you only have one, then they'd better be very good.
Otherwise, sure, make your own framework to learn architectural principals, to improve your ability to digest the architecture of production frameworks, and to improve your ability to extend the framework into areas that are unique to your use case. Just keep it out of production.
[disclaimer to avoid discussion forks: for this comment, I'm assuming that the framework is being used for non-trivial systems, if what you're doing is trivial, then you may not need a framework at all, bespoke or otherwise. I'm not particularly interested in the question of what constitutes a non-trivial system. Set the bar wherever it makes sense to you to consider significant code reuse imperative.]
Re: Do Not Learn Frameworks – Learn the Architecture
#69I have been doing web development for last 1 year. Can someone recommend a resource to learn Architecture?
Learning and looking at the internals of frameworks like Rails and Pyramid can be useful.
There's a good book http://aosabook.org/en/index.html called the Architecture of Open Source Applications.
More generally, you might find it useful to read Christopher Alexander's Timeless Way of Building.
Re: Do Not Learn Frameworks – Learn the Architecture
#70Earlier quoted context omitted.
> It can't be, because all the people spending their time on bespoke solutions are solving the same problems over and over again separately, whereas the people working on shared solutions keep building off each other. Over the long-run it gives a massive quality advantage to the shared solutions. In theory, yes. In the real world, "the people working on shared solutions" get distracted too easily, follow latest BS fa…
>What's even worse most frameworks are not that extendable without going out of your way when you need some custom functionality. So as soon as your problem becomes interesting, and you could really use some help from a framework, it's when they tend to break and you have to work around them... Then you discover the framework designers consider your problem too far from their core target use cases and so show no inte…
> Then you discover the framework designers consider your problem too far from their core target use cases and so show no interest in improving that area of the framework. The community question why on earth you were trying to solve that problem in the framework in the first place, and tell you that obviously you should have used a different framework from the start.
Either they're right or they're wrong. If they're wrong, then you have a golden opportunity to start contributing to the framework yourself by writing the extensions, incorporating them into your projects, sending them upstream when they're ready. If they're wrong then you'll be able to work that into your development workflow and you won't lose any speed by packaging up a PR or whatever.
If they're right then this will feel like pulling teeth.