Hacker News Books

Architecture of Doom is a good blog for those who are interested in brutalism: http://architectureofdoom.tumblr.com/

The article is about online or for me, on laptop, but I also have a 32GB Kindle Paperwhite on to which I download a ton of PDFs, mostly papers but some books. For example, I concatenated Onur Mutlu's Architecture lecture slides into a one GB PDF file. I like that that the papers look like papers and that the fonts and graphics are rendered correctly. Links work but I don't use them.

However, PDFs on the Paperwhite don't make for easy reading. I could and have converted papers to EPUB which is much easier for reading but less good for studying, and the purpose of these PDFs is studying. Yeah, I can grouse about PDFs but it's a tool which I use.

By comparison, I check EPUBs out from the library and they are surprisingly pleasant to read on the Paperwhite.

Yeah, the article is about the web and I'm answering about the Paperwhite. Maybe they have a point about browsing on the web. But for content meant to be read, for academic content, PDFs are pretty good.

BTW, on my MacBook I use Skim which is much better than Reader.

@jaw - I have; but first, a rant:

Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being over-engineered, not scalable, "done by contractors who don't know anything/are trying to pad billable hours", et cetera.

I can see this in the kind of schlock being peddled as the next great front-end/web solution; usually done by people who would do very well to revisit the last 30-40 years in thinking about the Design of software. Thinking that testing and TDD are replacements for and/or better than static typing is Pretty Fucking Stupid™.

Design Patterns as given by GoF, Fowler, etc are more often than not questionable, but design patterns extracted from your code base are worth their weight in gold.

We have a beefy .NET codebase composed of some 80+ projects (used to be more then we trimmed it down) integrating with 25+ external data sources/APIs and we have leveraged every single fucking thing out there to make sense of it and not let it overwhelm our systems.

Type-level invariants along with a layered validation system is definitely something that we made a bet early on and it paid off. It's very hard to mess it up once it is in place, and not that difficult to understand.

Some of the things we applied are discussed in Enterprise Architecture by Fowler, the Domain Driven Design book also discusses it a bit. Your own application of these principles is what matters, and that's where things get hairy.

.NET/C# is nice because it provides enough facilities through Reflection and Attributes to be able to "pattern"-ize some of the things that come up, and there are other languages that do it better still. I really like Ruby's method_missing and I wish that C# provided an equivalent, but to my knowledge most of the approaches within C# to do something like that are kludges at best.

> A simple, small, unpainted cinder block shack doesn't hide its materials, is made of raw concrete, but probably isn't brutalist. Neither is a brick victorian.

> The idea that beautiful forms can come from purely functional design without needing to cover things up with baroque decoration is really a central theme.

Huh? These two are contradictory statements. I recommend giving this a read, Architecture is where brutalism first sprung up: https://www.nytimes.com/2016/10/06/t-magazine/design/brutali...

It is a pity that so much effort has been put on writing/designing this booklet. Software Architecture is very hard to 'compress' into a booklet this size. And the concepts explained seem all mixed up. Also, I never understood the difference between Software Architect and Solution Architect, I think they are just marketing tags to specify a bit more what you can do as an architect (install/customize a turn-key solution, networking architecture, software development guidance from scratch, etc).

There is so much noise in the space of Software Architecture. And I think is something natural: building software is not architecture, nor engineering, nor mathematics... still it is all that at the same time. It also has strong social, linguistic and design components. Maybe it is just too new a discipline to define it clearly.

Personally I find these resources more convincing than the booklet or the references mentioned inside it:

For the technical/organizational (Dev teams) part

Architecture without Architects: https://www.youtube.com/watch?v=qVyt3qQ_7TA

Clean Architecture: https://www.youtube.com/watch?v=Nsjsiz2A9mg

https://www.amazon.com/Things-Architect-Knows-About-Transfor...

https://www.enterpriseintegrationpatterns.com

For the Enterprise Architect part:

https://www.amazon.com/Organizational-Culture-Leadership-Edg...

https://www.amazon.com/Chess-Enterprise-Architecture-Gerben-...

https://www.youtube.com/watch?v=ScHG63YmJ2k

There are quite a few things you need to learn to be able to program well. One of the easy ones is syntax, which is what you have to learn to go from one language to another, in addition to the names of variables/functions.

What is much harder to learn, and is largely language independent is:
1) Problem solving - the ability to break problems down into simple task that then can be trivially solved.
2) Data structures - programs are unless unless they have data to work with. Knowing how to best represent it is vital, do you use an array, linked list, tree etc.
3) Algorithms - known ways of operating on data to produce some out come. Everything from using a loop to add numbers, to sorting lists, or adding a node to a red-black tree.
4) Design Patterns - know ways to structure code, in a tried and tested fashion.
5) Architecture and Interface design - how to structure your project as a whole (what goes where) and how to set how one portion interacts with all the others.

Along with many other things. Point being the first language you learn matters little, if you learn to program that cross any language barrier. I have not touched the first language I learned for almost a year, but have learned 2 others in that time.

Having said all that, I am most at home in Python because there I know many of the language specific features.

Over the years I've found the following CS books helpful, but only a minority in my day-to-day work. Your mileage may vary, as would the utility of these to you.

Algorithms -> Algorithms + Data Structures = Programs by Wirth (worth its weight in gold if you can get past the Pascal syntax)

OS -> Operating System Concepts by Silberschatz et al (The dinosaur book)

CS Theory -> Introduction to Automata Theory, Languages, and Computation by Hopcroft, Ullman

Programming Languages Theory -> Programming languages: design and implementation by Pratt et al

Database Theory -> Database Design by Wiederhold

Architecture -> Structured Computer Organization by Andrew S Tanenbaum