# Modelling Published articles for Modelling. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Formal Methods Only Solve Half My Problems DevFeed: [Formal Methods Only Solve Half My Problems]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2022-06-02T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Formal methods](), [distributed-systems](), [benchmarking](), [Protocol (disambiguation)](), [Latency](), [Availability](), [Hardware](), [Simulation and Design]() Tags: [availability](), [benchmarking](), [complexity](), [cost](), [design](), [distributed-systems](), [formal-methods](), [hardware](), [latency](), [modelling](), [network](), [prototypes](), [scale](), [simulation](), [verification]() ### AI overview The article argues that formal methods such as TLA+ and P are highly valuable for finding bugs, exploring designs, and documenting protocols in large-scale distributed systems, but they address only part of the questions engineers face. It presents prototyping, closed-form modelling, benchmarking, and simulation as complementary techniques for evaluating latency, cost, hardware needs, availability, durability, overload behavior, and sensitivity to network conditions. ### Source excerpt Formal Methods Only Solve Half My Problems At most half my problems. I have a lot of problems. The following is a one-page summary I wrote as a submission to HPTS'22. Hopefully it's of broader interest. Formal methods, like TLA+ and P, have proven to be extremely valuable to the builders of large scale distributed systems1, and to researchers working on distributed protocols. In industry, these tools typically aren't used for full verification. Instead, effort is focused on interactions and protocols that engineers expect to be particularly tricky or error-prone. Formal specifications play multiple roles in this setting, from bug finding in final designs, to accelerating exploration of the design space, to serving as precise documentation of the implemented protocol. Typically, verification or model checking of these specifications is focused on safety and liveness. This makes sense: safety violations cause issues like data corruption and loss which are correctly considered to be among the most serious issues with distributed systems. But safety and liveness are only a small part of a larger overall picture. Many of the questions that designers face can't be adequately tackled with these methods, because they lie outside the realm of safety, liveness, and related properties. What latency can customers expect, on average and in outlier cases? What will it cost us to run this service? How do those costs scale with different usage patterns, and dimensions of load (data size, throughput, transaction rates, etc)? What type of hardware do we need for this service, and how much? How sensitive is the design to network latency or packet loss? How do availability and durability scale with the number of replicas? How will the system behave under overload? We address these questions with prototyping, closed-form modelling, and with simulation. Prototyping, and benchmarking those prototypes, is clearly valuable but too expensive and slow to be used at the exploration stage. Deve ## Cracking PostgreSQL Interview Questions DevFeed: [Cracking PostgreSQL Interview Questions]() Original publisher: [Read original article]() Author: Ant Wilson Published: 2021-02-27T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [PostgreSQL](), [SQL](), [Databases](), [Structured-data](), [Supabase]() Tags: [data](), [database](), [how-to](), [index](), [interview](), [modelling](), [performance](), [postgresql](), [schema](), [software-engineer](), [sql](), [technical]() ### AI overview A guide to preparing for PostgreSQL technical interviews, focusing on transactional SQL rather than analytical SQL. It covers relationship modeling, normalization, foreign keys, PostgreSQL data types such as JSONB, schemas, indexes, and query-plan analysis with EXPLAIN ANALYZE. ### Source excerpt Understand the top PostgreSQL Interview Questions ## Shopify's Data Science & Engineering Foundations DevFeed: [Shopify's Data Science & Engineering Foundations]() Original publisher: [Read original article]() Author: Marc-Olivier Arsenault Published: 2020-06-18T16:16:00Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Shopify](), [Data Science](), [data](), [Apache Spark]() Tags: [analysis](), [data-science](), [ecosystem](), [engineering](), [github](), [modelling](), [shopify](), [spark]() ### AI overview Shopify's Data Science & Engineering team describes foundational practices for data warehousing and analysis. The article emphasizes shared dimensional-modelling principles, consistent schemas, accessible data models, and a common Spark-based platform in a shared GitHub repository. These practices help teams work faster, collaborate across organizational boundaries, and provide reliable insights to Shopify's stakeholders, merchants, and partners. ### Source excerpt Shopify's Data team uses these foundational approaches to data warehousing and analysis empowering us to deliver the best results for our ecosystem. ## My top 5 must-have technical books DevFeed: [My top 5 must-have technical books]() Original publisher: [Read original article]() Author: Miguel Angel Quiñones Published: 2018-01-28T19:06:09Z Content type: opinion Language: en Sources: [Miguel Quinones]() Topics: [Programming](), [Testing](), [Domain-driven design (DDD)](), [Unit testing](), [Software](), [Algorithms, Complexity]() Tags: [books](), [complexity](), [modelling](), [opinion](), [programming](), [technical](), [testing]() ### AI overview The article recommends five technical books for software engineers, especially junior engineers: The Pragmatic Programmer, The Art of Unit Testing, Seven Languages in Seven Weeks, Domain-Driven Design, and The Algorithm Design Manual. It highlights self-improvement, maintainable tests, programming-language paradigms, software modeling, complexity, and algorithmic problem solving. ### Source excerpt Quite recently a team member wanted to suggest interesting technical books to read for a junior engineer. I figured I might as well write my top 5 books here, in no particular order. I believe every Software Engineer should own these books, but reading them is a very good start ;) The Pragmatic Programmer: From journeyman to master If you have to read just one book, specially when starting to write software, it should be The Pragmatic Programmer. It covers ideas, always focused on self-improvement, mastery of the craft, and professinalism. I see this book as an extended list of ideas and suggestions for self-improvement, similar to the programmer competency matrix. While reading it, it's better to keep growing a list of topics to investigate further, as the book covers wildly different practices, ideas, and techniques. The Art of Unit Testing This book opened my eyes into the world of unit testing, from a practical (not philosophical) point of view. It introduced me to practical techniques to use in unit testing. Most imporptantly, it helps understand the crucial understanding of the necessity of maintainable test code, and 'good' tests. I think it's the best introductory book on unit testing. Period. Seven Languages in Seven Weeks More than a book, "Seven Languages in Seven Weeks" is an exploration into wildly different concepts across programming languages. It's a book about paradigms, and crucially, sparks the curiosity of why these exist at all. The way that the concepts are introduced, focusing on the reasons, advantages, disadvantages and design decisions of a language were very insightful for me. If you don't try the proposed challenges the book still will give you a lot of material to think about and to take ideas from. Domain-Driven Design Most software projects are about tackling complexity, and I must say many projects fail in this regards. The book taught me how to think about the act of writing code in a more abstracted way, as a modelling problem. Eric ## Deep Probabilistic Modelling with Gaussian Processes #NIPS2017 DevFeed: [Deep Probabilistic Modelling with Gaussian Processes #NIPS2017]() Original publisher: [Read original article]() Published: 2017-12-04T12:00:00Z Content type: tutorial Language: en Sources: [Alex Korbonits]() Topics: [Tutorial](), [VAE](), [Machine learning](), [Deep learning](), [Neural Network](), [NeurIPS]() Tags: [analysis](), [bias](), [conference](), [data](), [deep-learning](), [gaussian](), [inference](), [modelling](), [neural-network](), [neurips](), [probabilistic](), [research](), [supervised-learning](), [theory](), [tutorial](), [unsupervised-learning](), [videos]() ### AI overview Lecture notes from a NeurIPS 2017 tutorial introduce deep probabilistic modelling with Gaussian processes, covering probabilistic neural networks, uncertainty, graphical models, and the computational challenge of inference. ### Source excerpt Lecture notes from Neil Lawrence's NIPS 2017 tutorial on deep probabilistic modelling with Gaussian processes -- from GPs to deep GPs and variational inference. ## Modelling Is Everything DevFeed: [Modelling Is Everything]() Original publisher: [Read original article]() Author: Martin Thompson (noreply@blogger.com) Published: 2011-09-02T18:23:00Z Content type: opinion Language: en Sources: [Mechanical Sympathy]() Topics: [Domain-driven design (DDD)](), [systems](), [Development](), [Code](), [Cache](), [cpu](), [Network]() Tags: [code](), [ddd](), [design](), [development](), [domain-driven-design](), [modelling](), [performance](), [systems]() ### AI overview The article argues that modelling what needs to be implemented is the most important step in software development, especially when building high-performance systems. It connects Domain-Driven Design with modelling the problem domain and explains that understanding CPU, memory, storage, cache, and network behavior can improve correctness and performance. ### Source excerpt I'm often asked, "What is the best way to learn about building high-performance systems"? There are many perfectly valid answers to this question but there is one thing that stands out for me above everything else, and that is modelling. Modelling what you need to implement is the most important and effective step in the process. I'd go further and say this principle applies to any development and the rest is just typing :-) Domain Driven Design (DDD) advocates modelling the domain and expressing this model in code as fundamental to the successful delivery and ongoing maintenance of software. I wholeheartedly agree with this. How often do we see code that is an approximation of the problem domain? Code that exhibits behaviour which approximates to what is required via inappropriate abstractions and mappings which just about cope. Those mappings between what is in the code and the real domain are only contained in the developers' heads and this is just not good enough. When requiring high-performance, code for parts of the system often have to model what is happening with the CPU, memory, storage sub-systems, or network sub-systems. When we have imperfect abstractions on top of these domains, performance can be very adversely affected. The goal of my "Mechanical Sympathy" blog is to peek at what is under the hood so we can improve our abstractions. What is a Model? A model does not need to be the result of a 3-year exercise producing UML. It can be, and often is best as, people communicating via various means including speech, drawings, illustrations, metaphors, analogies, etc, to build a mental model for shared understanding. If an accurate and distilled understanding can be reached then this model can be turned into code with great results. Infrastructure Domain Models If developers writing a concurrent framework do not have a good model of how a typical cache sub-system works, i.e. it uses message passing to exchange cache lines, then the framework is unlikely to ## Why developers should be force-fed state machines DevFeed: [Why developers should be force-fed state machines]() Original publisher: [Read original article]() Author: Willem van Bergen Published: 2011-06-13T14:41:00Z Content type: opinion Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Finite-state machine](), [web applications](), [math](), [Rails]() Tags: [awareness](), [bugs](), [developers](), [math](), [modelling](), [ruby](), [web-applications]() ### AI overview The article argues that developers of web applications should use finite-state machines to design and model domain objects. It explains that state machines expose edge cases, reduce bugs and undefined behavior, clarify external APIs, and draw on mathematical and computer science research. Examples include accounts, subscriptions, invoices, orders, and blog posts, with Ruby on Rails presented as an implementation option. ### Source excerpt This post is meant to create more awareness about state machines in the web application developer crowd. If you don't know what state machines are, please read up on them first. Wikipedia is a good place to start, as always. State machines are awesome The main reason for using state machines is to help the design process. It is much easier to figure out all the possible edge conditions by drawing out the state machine on paper.