217 Matching Annotations
  1. Last 7 days
    1. StylEx architecture.

      TLDR methodology: 1) StyleGAN + classifier 2) Search StyleSpace

  2. Dec 2021
    1. “Any large room looks wrong without the appropriate number of people in it,” Mr. Byers writes. “An unused living room looks empty. An empty ballroom is absolutely creepy; it looks as if it is waiting desperately for something to happen. A library, on the other hand, is delightful when full but still especially attractive when empty.”

      on the coziness of libraries

  3. Nov 2021
    1. Now this is getting too complex for discussing this here and these type of architectural decisions require more in depth understanding than what I can provide here.
    2. My UIs are data/store driven. The UI is just a way to visualize the data. Your data could flow through all of of the extensions and the extensions can make decisions (e.g. setting visible to false). Like middlewares in a Connect/Express/Polka app. And the UI doesn't even know about all this, it just updates with the current state and makes sure it's consistent.
  4. Oct 2021
    1. The main idea behind the space-based pattern is the distributed shared memory to mitigate issues that frequently occur at the database level. The assumption is that by processing most of operations using in-memory data we can avoid extra operations in the database, thus any future problems that may evolve from there (for example, if your user activity data entity has changed, you don’t need to change a bunch of code persisting to & retrieving that data from the DB).The basic approach is to separate the application into processing units (that can automatically scale up and down based on demand), where the data will be replicated and processed between those units without any persistence to the central database (though there will be local storages for the occasion of system failures).

      Space-based architecture

    2. Microservices architecture consists of separately deployed services, where each service would have ideally single responsibility. Those services are independent of each other and if one service fails others will not stop running.

      Microservices architecture

    3. First of all, if you know the basics of architecture patterns, then it is easier for you to follow the requirements of your architect. Secondly, knowing those patterns will help you to make decisions in your code

      2 main advantages of using design patterns:

      • easier to follow requirements of an architect
      • easier to make decisions in your code
    4. Mikrokernel Architecture, also known as Plugin architecture, is the design pattern with two main components: a core system and plug-in modules (or extensions). A great example would be a Web browser (core system) where you can install endless extensions (or plugins).

      Microkernel (plugin) architecture

    5. The idea behind this pattern is to decouple the application logic into single-purpose event processing components that asynchronously receive and process events. This pattern is one of the popular distributed asynchronous architecture patterns known for high scalability and adaptability.

      Event-driven architecture: high scalability and adaptability

    6. It is the most common architecture for monolithic applications. The basic idea behind the pattern is to divide the app logic into several layers each encapsulating specific role. For example, the Persistence layer would be responsible for the communication of your app with the database engine.

      Layered architecture

    1. Drawing on path-breaking research in archaeology and anthropology, the authors show how history becomes a far more interesting place once we learn to throw off our conceptual shackles and perceive what's really there.

      Reimagining our social architecture might begin with rethinking our past and origins as a species.

    1. Lean Canvas

      For the builders collective, I created some tools that are open source and useful for design and social architecture. Other projects are coding challenges to experiment with what is possible on the web.

      This experiment is based on the Lean Canvas, based on the Business Model Canvas from the book Business Model Generation.

      Type in the grey box at the top of the page. Click or tap in the boxes to add the text as a box in each section of the Lean Canvas. Click on the box to delete.

      There is no save functionality, so be sure to take a screenshot. Or roll your own by using the code on Codepen and GitHub.

    1. Education and job hiring should be integrated.

      Systemic Problems

      The problem is systemic. How do you deal with the problem when the system is off the table when it comes to the design problem?

    1. Regenerative Ventures

      Out of the Trimtab Space Camp course with the Buckminster Fuller Institute in which we were exploring world building with Tony Patrick, Langdon Roberts, Jeremy Lubman, Elsie Iwase, and I gathered to think about how we could become involved in regenerative ventures. This was our initiative, in which we met weekly to think about how we manifest who we are as a more beautiful world our hearts know is possible. The thought was that architecture grows out of values, principles, and intention.

    1. “The real problem of humanity is the following: we have paleolithic emotions; medieval institutions; and god-like technology.

      Quoted by Amanda Joy Ravenhill on RE & CO Radio, Wednesday, October 13, 2021.

      This leads to a sense of learned hopelessness: Things are worse than you imagined, and there is nothing you can do about it.

      But Buckminster Fuller said, “We are called to be the architects of the future, not its victims.”

    1. The rise of the Nazis in 1933 caused an unprecedented forced migration of hundreds of artists within and, in many cases, ultimately away from Europe. Exiles and Emigres, published in conjunction with a traveling exhibition opening in February 1997 at the Los Angeles County Museum of Art, is the first book to trace the lives and work of 23 well-known painters, sculptors, photographers, and architects exiled from their homelands during the 12 years of Nazi rule.

      “The Bauhaus concept, as it was transplanted to the United States, was fundamentally different from the principles upon which the experimental school had been founded in Weimar in 1919. The guiding principle of the Bauhaus was to unify all aspects of art making—painting, sculpture, handicrafts—as elements of a new kind of art, erasing the division between “high” and decorative art. Explorations of materials, color, and form were important building blocks of the curriculum. The artists and designers of the Bauhaus believed that this new type of art and design would help to create a better society, and they sought commissions to design public buildings and other elements of public life (such as flags and currency). In America, however, the Bauhaus ideas lost their social and political thrust. The emigré teachers in Chicago, Cambridge, and North Carolina who had been committed to progressive architecture and design ideas in Germany were now lionized as upholders of a pure, reductivist style.”

      (Stephanie Barron, page 25)

    1. Science-Driven Societal Transformation

      Gien Wong notes these three concept papers on Science-Driven Societal Transformation: Worldview, Motivation and Strategy, and Design.

    1. Because at the end of the day, all structures are, in some ways, ideology made manifest.

      Avery Trufelman ends her podcast series, Nice Try! with these words in an episode entitled, Germania: Architecture in a Fascist Utopia.

      One person’s utopia is another person’s dystopia.

      The structure of the mind becomes the architecture of our reality. This thought became the foundation for a mental model for human experience, since these architectural plans for utopia seem like good ideas on paper, but when we live inside these structure in our daily reality, we realize that we have constructed our own mental prisons, the iron cage envisioned by Max Weber.

    2. It spells out so clearly that Nazi Germany’s worst atrocities and many atrocities the world over were not only the ideas of singular evil men. They were supported and enacted by systems, by groups of people who woke up in the morning and went to offices to work on it.

      Avery Trufelman ends her podcast series, Nice Try! with these words in an episode entitled, Germania: Architecture in a Fascist Utopia.

    1. The Hidden History of the Geodesic Dome - Part 3: The Teamwork of Walter Gropius

      The Hidden History of the Geodesic Dome - Part 3: The Teamwork of Walter Gropius

      Understanding one’s limitations leads to a recognition of the power of relationships in an interconnected and interdependent world.

    2. Because of his handicap, Walter Gropius achieved his goals by working through other people, and harnessed their abilities to produce efficient and practical architecture.

      The Hidden History of the Geodesic Dome - Part 3: The Teamwork of Walter Gropius

      Understanding one’s limitations leads to a recognition of the power of relationships in an interconnected and interdependent world.

  5. Sep 2021
    1. Stop Reset Go

      How do we engage in bottom-up whole system change? Perhaps we need a model for understanding who we are serving that transcends the bias and limitations of personas as they are used in user experience design (UX).

      What is a more holistic model for understanding human perceptions, motivations, and behaviours?

    1. Another contributing factor was the conceptual freedom that we experienced in architecture school, something that is definitely lost when you move to the professional world. Software, we realized, still offered a bit more experimentation and personal creativity than architecture did in a real world context.
    1. Areas of Integrated Governance

      Major areas of integrated governance for enterprise architecture looks like Integrated Project Management Framework

    Tags

    Annotators

  6. Aug 2021
  7. Jul 2021
    1. I used to be very interested in Software Architecture, in fact I've read many of the papers cited here.When I did a startup many years ago, I committed the mistake of paying too much attention to the architecture of the software [1] I was writing, and not enough attention to the product/customer side of it.The last couple of years I've been de-emphasizing software architecture as an interest, and have been paying much more attention to how product teams build successful products, what the patterns are, etc. I was lucky enough to work at Facebook for a while and got to see (and learn) a very successful working model of product development.So, while I'm not saying that software architecture is not important (it is), also pay attention to the product/customer side: what choices (software, organizational, hiring, business) allow you to move fast and iterate, to release early and often, to run A/B tests, etc.I think good software engineers are just as much product guys (and data guys) as they are software guys.
    1. I've had this discussion with peer engineers working at other tech companies, FANG (Facebook, Amazon, Netflix, Google), as well as at smaller startups. Most teams and projects - however large or small - all shared a similar approach to design and implementation:Start with the business problem. What are we trying to solve? What product are we trying to build and why? How can we measure success?Brainstorm the approach. Get together with the team and through multiple sessions, figure out what solution will work. Keep these brainstormings small. Start at a high level, going down to lower levels.Whiteboard your approach. Get the team together and have a person draw up the approach the team is converging to. You should be able to explain the architecture of your system/app on a whiteboard clearly, starting at the high-level, diving deeper as needed. If you have trouble with this explanation or it's not clear enough, there's more work required on the details.Write it up via simple documentation with simple diagrams based on what you explained on the whiteboard. Keep jargon to the minimum: you want even junior engineers to understand what it's about. Write it using clear and easy to follow language. At Uber, we use an RFC-like process with various templates.Talk about tradeoffs and alternatives. Good software design and good architecture are all about making the right tradeoffs. No design choice is good or bad by itself: it all depends on the context and the goals. Is your architecture split into different services? Mention why you decided against going with one large service, that might have some other benefits, like more straightforward and quicker deployment. Did you choose to extend a service or module with new functionality? Weigh the option of building a separate service or module instead, and what the pros and cons of that approach would be.Circulate the design document within the team/organization and get feedback. At Uber, we used to send out all our software design documents to all engineers, until there were around 2,000 of us. Now that we're larger, we still distribute them very widely, but we've started balancing the signal/noise ratio more. Encourage people asking questions and offering alternatives. Be pragmatic in setting sensible time limits to discuss the feedback and incorporate it, where it's needed. Straightforward feedback can be quickly addressed on the spot, while more detailed feedback might be quicker to settle in-person.

      A good, high level overview on how to get started with architecture

  8. Jun 2021
    1. Worse still is the issue of “service” layers requiring you to basically build your own ORM. To really do a backend-agnostic service layer on top of the Django ORM, you need to replace or abstract away some of its most fundamental and convenient abstractions. For example, most of the commonly-used ORM query methods return either instances of your model classes, or instances of Django’s QuerySet class (which is a kind of chained-API results wrapper around a query). In order to avoid tightly coupling to the structure and API of those Django-specific objects, your service layer needs to translate them into something else — likely generic iterables to replace QuerySet, and some type of “business object” instance to replace model-class instances. Which is a non-trivial amount of work even in patterns like Data Mapper that are designed for this, and even more difficult to do in an Active Record ORM that isn’t.

      I see what this guy means and he has a point. However, I don't think about reimplementing these things when talking about services on Django. I want a centralized place to store business logic (not glue queries) and avoid multiple developers writing the same query multiple times in multiple places. The name "service" here sucks.

    2. A second problem is that when you decide to go the “service” route, you are changing the nature of your business. This is related to an argument I bring up occasionally when people tell me they don’t use “frameworks” and never will: what they actually mean, whether they realize it or not, is “we built and now have to maintain and train our developers on our own ad-hoc private framework, on top of whatever our normal business is”. And adopting the service approach essentially means that, whatever your business was previously, now your business is that plus developing and maintaining something close to your own private ORM.

      I don't think these two things are even close to be the same thing. Django's ORM is not replaced by services, from what I know services are the ORM with the difference that they are concentrated in a module.

    1. This isn't about writing boilerplate setter properties for each field in the model, but rather about writing methods that encapsulate the point of interaction with the database layer. View code can still inspect any field on the model and perform logic based on that, but it should not modify that data directly. We're ensuring that there is a layer at which we can enforce application-level integrity constraints that exist on top of the integrity constraints that the database provides for us.

      Addresses the issue raise on this tweet. We are not writing getters and setters out of obligation or convention.

    1. We should think about the number of simultaneous connections (peak and average) and the message rate/payload size. I think, the threshold to start thinking about AnyCable (instead of just Action Cable) is somewhere between 500 and 1000 connections on average or 5k-10k during peak hours.
      • number of simultaneous connections (peak and average)

      • the message rate/payload size.

    2. We use a single stream/queue/channel to deliver messages from RPC to WS. RPC server acts as publisher: it pushes a JSON-encoded command. Pubsub connection is initialized lazily in this case (during the first #broadcast call). WS server (anycable-go) acts as subscriber: subscription is initialized on server start, messages are received, deserialized and passed to the app.
  9. May 2021
  10. Apr 2021
    1. This post articulates a lot of what I've been thinking about for the past 18 months or so, but it adds the additional concept of community integration.

      Interestingly, this aligns with the early, tentative ideas around what the future of In Beta might look like as a learning community, rather than a repository of content.

  11. Mar 2021
    1. Werner Vogels, Amazon CTO, notes that one of the lessons we have learned at Amazon is to expect the unexpected. He reminds us that failures are a given, and as a consequence it’s desirable to build systems that embrace failure as a natural occurrence. Coding around these failures is important, but undifferentiated, work that improves the integrity of the solution being delivered. However, it takes time away from investing in differentiating code.

      This is an annotation I made.

    2. When asked to define the role of the teacher, for example, Reggio educators do not begin in the way typical to

      This is an annotation I made.

    3. This is an annotation I made.

    4. This is an annotation I made.

    5. This is an annotation I made.

    1. System architects: equivalents to architecture and planning for a world of knowledge and data Both government and business need new skills to do this work well. At present the capabilities described in this paper are divided up. Parts sit within data teams; others in knowledge management, product development, research, policy analysis or strategy teams, or in the various professions dotted around government, from economists to statisticians. In governments, for example, the main emphasis of digital teams in recent years has been very much on service design and delivery, not intelligence. This may be one reason why some aspects of government intelligence appear to have declined in recent years – notably the organisation of memory.57 What we need is a skill set analogous to architects. Good architects learn to think in multiple ways – combining engineering, aesthetics, attention to place and politics. Their work necessitates linking awareness of building materials, planning contexts, psychology and design. Architecture sits alongside urban planning which was also created as an integrative discipline, combining awareness of physical design with finance, strategy and law. So we have two very well-developed integrative skills for the material world. But there is very little comparable for the intangibles of data, knowledge and intelligence. What’s needed now is a profession with skills straddling engineering, data and social science – who are adept at understanding, designing and improving intelligent systems that are transparent and self-aware58. Some should also specialise in processes that engage stakeholders in the task of systems mapping and design, and make the most of collective intelligence. As with architecture and urban planning supply and demand need to evolve in tandem, with governments and other funders seeking to recruit ‘systems architects’ or ‘intelligence architects’ while universities put in place new courses to develop them.
    1. Here's the four case: foo.js Load/Require dependencies Concatenate dependencies foo.js.map Load foo.js Currently grabs metadata[:map] from asset to build an asset, need to move that generation somewhere else to accomplish de-coupling map generation foo.debug.js Load foo.js Load foo.js.map Add comment to end of foo.js with path to foo.js.map foo.source.js The raw file on disk, the map file will need to point to source files.
  12. Feb 2021
    1. Software architecture is about making fundamental structural choices that are costly to change once implemented.
    2. Software architecture refers to the fundamental structures of a software system
    3. Software architecture choices include specific structural options from possibilities in the design of the software.
    1. The adapter is where authentication, policy checks, and eventually your domain logic happen. All termini of the protocol’s activity are standardized end events - that’s how protocol and adapter communicate.
    1. And really, this stems from the fact that buildings aren't designed by the community that uses them anymore. The community barely factors into the design, even. Buildings were designed to serve a specific purpose, dictated by the higher-ups with the money to purchase the land and fund the development of the building. Again, quoting the article, Unless they are an uber-wealthy client, users of buildings rarely have much input into the design process. Students do not get to say what kind of school they would like, office workers do not get to say whether they would prefer to work in a glass tower or in a leafy complex of wifi-enabled wooden pagodas. ... But that rupture means that architecture becomes something imposed upon people. It isn’t participatory, and it doesn’t adapt in response to their needs. It’s prefabricated, assembled beforehand off-site and then dumped on the unwitting populace. We are not meant to live in modern buildings; they are made for people who do not poop.

      This is very reminiscent of how some people use the internet as well. I can think of personal examples where Goolge apps and services were forced upon workers at companies who didn't want them and weren't comfortable with them.

      Similarly we went from the creativity of MySpace to the corporate strictures of Facebook and Twitter that didn't give users any flexibility or identity. The connective value was apparently worth just a bit more than the identity, so we went there, but why not have it all?

      I'll have to find the reference, but I saw an article with a book reference in the last year about the life of buildings and that well designed ones could stand the test of centuries in their ability to be redesigned and repurposed from the inside out if necessary.

  13. Jan 2021
    1. https://hyp.is/go?url=https%3A%2F%2Fwww.archdaily.com%2F627654%2Fthe-computer-vs-the-hand-in-architectural-drawing-archdaily-readers-respond&group=__world__

      I came across this article about the tension between computer drawing and hand drawing in architecture when I replied to an annotation by another user @onion - very interesting read and I would be curious to see this issue revisited in another ten years...how may opinions have changed?

  14. Nov 2020
    1. Micro is a platform for cloud native development. It addresses the key requirements for building services in the cloud. Micro leverages the microservices architecture pattern and provides a set of services which act as the building blocks of a platform. Micro deals with the complexity of distributed systems and provides simpler programmable abstractions to build on.

      What they are doing is like AWS lambda - BUT - they abstract away the details of things like Auth, pub/sub, config, networks AND the DB (which is a KV store).

      So you simply write your services letting the platform take care of the particulars of adjacencies.

    1. There are, as you’re about to see, lots of problems with PGP. Fortunately, if you’re not morbidly curious, there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography. No competent crypto engineer would design a system that looked like PGP today, nor tolerate most of its defects in any other design. Serious cryptographers have largely given up on PGP and don’t spend much time publishing on it anymore (with a notable exception). Well-understood problems in PGP have gone unaddressed for over a decade because of this.

      The meta-problem with PGP is that it was designed by crypto-engineers in the 90s and it is horribly outdated, yet due to its federated architecture, difficult to update.

    1. So while it’s nice that I’m able to host my own email, that’s also the reason why my email isn’t end-to-end encrypted, and probably never will be. By contrast, WhatsApp was able to introduce end-to-end encryption to over a billion users with a single software update.

      Although the option to host your own email offers you freedom, it's precisely this freedom that makes change more difficult and the reason why email isn't yet end-to-end encrypted.

      Centralized architectures, like whatsapp, allow you to roll out end-to-end encryption to the entire network with 1 software update.

    2. That has taken us pretty far, but it’s undeniable that once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don’t fare very well in a world where the ecosystem is moving.

      Because the ecosystem around software application is quickly evolving, you need to be able to adapt in order to be competitive.

      Once you federate your technology, however, you lose this ability to adapt quickly, as is evidenced by the relative stagnation of federated standards such as IP, SMTP, IRC, DNS etc.

    3. This reduced user friction has begun to extend the implicit threat that used to come with federated services into centralized services as well. Where as before you could switch hosts, or even decide to run your own server, now users are simply switching entire networks.

      The implicit threat of federated architectures is also emerging in centralized services. It emerges there because the core of the social network, the address book, is saved locally (i.e. federated). This makes it easy for users to switch networks, and this ease keeps the providers honest.

    4. Given that federated services always seem to coalesce around a provider that the bulk of people use, federation becomes a sort of implicit threat. Nobody really wants to run their own servers, but they know that it might be possible if their current host does something egregious enough to make it worth the effort.

      The implicit threat of federation

      In a federated architecture, most users tend to coalesce around one provider. Few actually want to run their own server, but the fact that that option exists, acts as an implicit threat which keeps the current host honest.

    5. In a way, the notification center on a mobile device has become the federation point for all communication apps, similar to how older desktop IM clients unified communication across multiple IM networks.

      Mobile device's notification centers are federation points for communication apps

      The notification center in our phones acts as a hub where messages show up from WhatsApp, Telegram, SMS etc. analogous to how older desktop IM clients unified communication across multiple networks.

    6. Federation gives us more collective control over what changes we accept, but that comes with an unacceptable inability to adapt.

      A federated model requires some type of consensus to form to accept changes. This is great to promote consensus, but reaching consensus takes time and results in an inability to adapt quickly.

  15. Oct 2020
    1. So that’s already a huge advantage over other platforms due the basic design. And in my opinion it’s got advantages over the other extreme, too, a pure peer-to-peer design, where everyone would have to fend for themselves, without the pooled resources.

      Definitely something the IndieWeb may have to solve for.

    2. Mastodon deliberately does not support arbitrary search. If someone wants their message to be discovered, they can use a hashtag, which can be browsed. What does arbitrary search accomplish? People and brands search for their own name to self-insert into conversations they were not invited to. What you can do, however, is search messages you posted, received or favourited. That way you can find that one message on the tip of your tongue.
    1. 2011-06-23 at OSBridge2011 having lunch with Ward, Tantek exclaimed: The Read Write Web is no longer sufficient. I want the Read Fork Write Merge Web. #osb11 lunch table. #diso #indieweb

      This is what I want too!

    1. And we see that develop into the web as we know it today. A web of “hey this is cool” one-hop links. A web where where links are used to create a conversational trail (a sort of “read this if you want to understand what I am riffing on” link) instead of associations of ideas. The “conversational web”. A web obsessed with arguing points. A web seen as a tool for self-expression rather than a tool for thought. A web where you weld information and data into your arguments so that it can never be repurposed against you. The web not as a reconfigurable model of understanding but of sealed shut presentations.
    1. We are beginning a renovation of our main library at Northeastern University, Snell Library, and have been talking with architects (some of them very well-known), and I’ve found the discussions utterly invigorating. I would like to find some way to blog or newsletter about the process we will go through over the next few years, and to think aloud about the (re)design and (future) function of the library. I’m not sure if that should occur in this space or elsewhere, although the thought of launching another outlet fills me with dread. Let me know if this topic would interest you, and if I should include it here.

      Definitely interesting. Please include it here or on your main site!!!

    1. Un premier élément qui marque la spécificité du milieu numérique se joue dans la nature du texte numérique, devenu à la fois support, dispositif et milieu.
    2. je retiens en particulier le fait que l’éditorialisation est un processus. Cette notion est importante, car elle marque une rupture avec l’édition.

      architecture (de l'information) -> processus (par opposition à une structure, statique, comme un livre)

      ainsi architecture et éditorialisation (comme phénomènes numériques) sont liées

    1. Here's one quick way to test if your application has properly segregated itself between the Model, View, and Controller roles: is your app skinnable? My experience is that designers don't understand loops or any kind of state. They do understand templates with holes in them. Everybody understands mail merge. And if you say, "Apply the bold template to this hole," they kind of get that, too. So separating model and view addresses this very important practical problem of how to have designers work with coders. The other problem is there is no way to do multiple site skins properly if you don't have proper separation of concerns. If you are doing code generation or sites with different skins on them, there is no way to properly make a new skin by simply copying and pasting the old skin and changing it. If you have the view and the logic together, when you make a copy of the view you copy the logic as well. That breaks one of our primary rules as developers: have only one place to change anything.

      An effective way of testing whether your app practices separation of concerns within the MVC paradigm is whether or not it is "skinnable"

    1. In 1972 David L. Parnas published a classic paper entitled On the Criteria To Be Used in Decomposing Systems into Modules. It appeared in the December issue of the Communications of the ACM, Volume 15, Number 12. In this paper, Parnas compared two different strategies for decomposing and separating the logic in a simple algorithm. The paper is fascinating reading, and I strongly urge you to study it. His conclusion, in part, is as follows: “We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”

      Parnas published a paper in 1972 about what heuristics are best to decide when to decompose a system into modules.

      His conclusion is that it is almost always wrong to start with a representation such as a flowchart (because things change).

      Instead he recommends focusing on a list of difficult design decisions, or decisions, once made, that will likely change. Then design each module is designed to hide such decisions from others.

    1. Domain-driven design separates the model layer “M” of MVC into an application, domain and infrastructure layer. The infrastructure layer is used to retrieve and store data. The domain layer is where the business knowledge or expertise is. The application layer is responsible for coordinating the infrastructure and domain layers to make a useful application. Typically, it would use the infrastructure to obtain the data, consult the domain to see what should be done, and then use the infrastructure again to achieve the results.

      Domain Driven Design separates the the Model in the MVC architecture into an application layer, an infrastructure layer and a domain layer.

      The business logic lives in the domain layer. The infrastructure layer is used to retrieve and store data. The application layer is responsible for coordinating between the domain and infrastructure layer.

  16. Sep 2020
    1. He claims that chip makers have erected a new Berlin Wall in between the user and the microprocessor: “And so, software— a billion- dollar enterprise based on one of the cheapest elements on Earth— used everything at its disposal to prevent said ‘humans’ from having access to hardware” (209).

      accès au microprocesseur: le mur de Berlin comme parallèle architectural + géopolitique

      les microprocesseurs créent une barrière, mais dans un sens différent: une barrière d’échelle (difficulté d’accès parce que les puces sont microscopiques, elles ne peuvent être manipulées à mains nues).

    2. If code governs so much of our lives, then to understand its operations is to get some sense of the systems that operate on us.

      pour une architecture (espaces habitables) de l’information (environnements informationnels)

      Comment rendre l’information habitable?

    1. Developing software is usually easier if you break your project into smaller separate pieces, since that often removes unexpected interactions and dramatically reduces the complexity of the problems you'll need to solve
  17. Aug 2020
    1. The RAT model sees software development as an off-line program-construction activity composed of these parts: defining, decomposing, estimating, implementing, assembling, and finishing

      This is what can lead to the 'there is only version 1.0' problem - and improvements / iterations fall to the sidelines.

      This can have a number of consequences

      • over designed / engineered
      • doing unnecessary work
      • lack of user feedback and ability to accommodate it
      • rigid / fragile architecture
    1. Choice architecture is a concept introduced in the book Nudge by Richard Thaler (who would go on to win a Nobel Prize for some of this work) and Cass Sunstein. The basic concept is that how an environment is designed influences the decisions people make in that environment.

    Tags

    Annotators

    1. “When the environment itself is constituted by electric circuitry and information, architecture becomes the content of the new information environment. Architecture is the old technology which is automatically elevated into an art form.”
    2. electronics presents new challenges to planners because this latest prosthetic extension of the body defines an entirely new form of space.
    1. reducing the presence of those things we usually call “architecture” demands that we return to what is most effective about architecture and the way it frames social relationships
  18. Jul 2020
  19. Jun 2020
    1. Mr. Speyer’s most famous work is the Ben Rose House near Chicago, a modern glass box known for its supporting role in the 1986 movie ”Ferris Bueller’s Day Off.” Mr. Speyer studied architecture under famed modernist Mies van der Rohe at the Illinois Institute of Technology, and later became curator of 20th century painting and sculpture at the Art Institute of Chicago.

      architecture, art, Ferris Bueller's Day Off

    2. Mr. Speyer was critical of American home-building bombast, declaring in a 1986 interview conducted by the Art Institute of Chicago shortly before his death, “I think the typical suburban style is really not at all based in comfort, it’s based in ostentation,” he said. “Everybody,” he added, is “putting a centerpiece on the table.”
    1. This integration of digital tools and automated technologies into building practices has become ever-more urgent in light of the agility that will be required to cope with the effects of climate change, including the increased mobility of people and reduction in material and human resources. Architecture that could accommodate more people in the event of mass migration, or construction practices that could efficiently utilise local resources instead of relying on global supply chains, are possible results of digitising the production of the built environment.

      As long as the tools are made freely available to the public, lest the control shift to those who own/control such tools (proprietary software in the hands of large digital coroporations).

  20. May 2020
    1. The overall software architecture is actioning years of developers experiences through Uncle Bob's Clean Architecture. Thanks to Lerna and Yarn workspaces, GanttLab now comes with the entities, use-cases and gateways packages that are used by the adapter-webapp making up the web application on https://app.ganttlab.com.
    1. What is Serverless Architecture? Its Pros & Cons

      Serverless Architecture is a new way of handling development projects with its thrilling benefits. Still, what benefits of serverless Architecture for you depends on your business needs.

    1. “As I enter the office floor, I see my colleagues, wave to them, and find myself a desk. I overhear some guys talking about an old client of mine. I give them some tips on how I used to handle this client, but I really don’t have time to chitchat. My new client will arrive in an hour; a key account and we cannot afford to lose him. I’m damn nervous and I need to prepare. So, I pick up my laptop and move into one of the available quiet rooms. I close the door and start working.” This straightforward story explains the advantages of the open office, as well as the users’ fears of not being able to concentrate, and the potential business implications of distracted workers. And the story provides a possible design solution (creating ‘quiet rooms’), which proved to be valuable input in the design process (they got their quiet rooms).

      Example of an effective and authentic narrative.

  21. Apr 2020
    1. Web Application Architecture – Its Components & TypesYou are here:HomeApps & SoftwareWeb Application Architecture – Its…

      A web application that works on the remote server with the help of the internet. The app is stored on the remote server and gets delivered over the browser interface.

    1. Guédelon Castle (Château de Guédelon) is a castle currently under construction near Treigny, France. The castle is the focus of an experimental archaeology project aimed at recreating a 13th-century castle and its environment using period technique, dress, and material.

      Guédelon Castle (Château de Guédelon)

      More info on HN

    1. la ville comme teaching machine : cet environnement, réceptacle d’information, devient support d’un apprentissage

      l'architecture en elle-même est donc sémantique, porteuse de sens – et non pas simple support technique.

    2. Ainsi l’architecture a eu, à un moment de l’histoire, la capacité de rendre visibles les supposées qualités (spatiales) d’un environnement numérique en cours de co-construction par les informaticiens et les architectes, un espace redéfini comme pur milieu d’apprentissage
    3. quand l’environnement lui-même est constitué de circuits électroniques et d’information, l’architecture devient le contenu d’un nouvel environnement informationnel

      renversement de l’architecture traditionnelle: dans l’environnement informationnel, le contenant (architecture, comme structure) devient le contenu.

    4. l’architecture comme un cadre d’élaboration de la pensée informatique a été bien documentée

      l’architecture s’entend ainsi comme cadre épistémologique, une condition du réel permettant le cheminement de la pensée, son articulation, sa cristallisation.

    5. dispositif de réorganisation permanente du site par ses habitants

      c’est d'ailleurs la qualité du mobilier urbain que d’être appropriable par ses occupants (ex. déplacer une chaise dans une place publique, ne serait-ce que de quelques centimètres ou en la tournant de quelques degrés: par ce simple geste, on se l'approprie, même si c'est un bien commun; contrairement à un banc fixé dans le béton, la chaise déplaçable permet d'assouplir (soft-en) l’environnement urbain pour qu’il puisse être plié aux usages)

    6. Ainsi, par le recours aux outils informatiques, la pratique architecturale se voit coupée en deux (opérant par là le renversement d’un paradigme accepté par la discipline depuis Alberti) : une partie hard dont l’architecture est responsable, et une partie soft rendue aux habitants

      dualité du régime de vie du projet architectural: la partie hard, la structure, celle dessinée par les architectes, et la partie soft – dynamique, imprévisible, dont s’empare les citoyens.

    1. Au lieu de « Que nul n’entre s’il n’est géomètre » , « Que nul n’entre s’il n’est codeur ».

      excellent slogan pour l'école d'architecture (numérique) du XXI siècle!

    1. Peut-être, au lieu que d’espace numérique, nous devrions parler d’architectures numériques, en donnant au mot « architecture » une signification à la fois spatiale et temporelle. Le nuage est une architecture, l’infrastructure d’Internet est une architecture, et l’ensemble d’algorithmes, données, plateformes et câbles est une architecture.
    2. Arrêtons-nous-y : parler musicalement de l’espace est une façon de l’investir de temps (au pluriel), de l’aérer avec des rythmes, de changer (par accélération) la hauteur nombrée en durée rythmée.

      la musique comme métaphore de l'exploration de l'espace-temps

  22. Mar 2020
    1. different problems that are sufficiently similar that you can apply a same model to them, but sufficiently different that this model has to be customized considerably to be applicable in each case.

      Equivalent Problems

    1. les communs tendent à se définir par les modalités et l’intention de leur gouvernance, plus que par la seule préservation de ressources. C’est cette architecture de gouvernance en mouvement, et l’écosystème humain qui en résulte, qui constituent les communs.

      questionne la finalité des communs et renverse ce qui est commun : «l'architecture de gouvernance en mouvement»