#diagram — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #diagram, aggregated by home.social.
-
Simple Combinations of Upper Lid and Brow (1886), from Delsarte System of Dramatic Expression.
Source: University of Toronto Libraries / Internet Archive
Available to buy as a print.
https://pdimagearchive.org/images/37f8375b-b9b3-4506-b2d7-1174873eae08
#charts #vision #wrinkles #diagram #drama #acting #notation #gesture #furrows #theatre #eyecharts #dramaticpose #expression #facialexpressions #eyes #bookillustration #diagrams #printmaking #line #art #publicdomain
-
Simple Combinations of Upper Lid and Brow (1886), from Delsarte System of Dramatic Expression.
Source: University of Toronto Libraries / Internet Archive
Available to buy as a print.
https://pdimagearchive.org/images/37f8375b-b9b3-4506-b2d7-1174873eae08
#charts #vision #wrinkles #diagram #drama #acting #notation #gesture #furrows #theatre #eyecharts #dramaticpose #expression #facialexpressions #eyes #bookillustration #diagrams #printmaking #line #art #publicdomain
-
Simple Combinations of Upper Lid and Brow (1886), from Delsarte System of Dramatic Expression.
Source: University of Toronto Libraries / Internet Archive
Available to buy as a print.
https://pdimagearchive.org/images/37f8375b-b9b3-4506-b2d7-1174873eae08
#charts #vision #wrinkles #diagram #drama #acting #notation #gesture #furrows #theatre #eyecharts #dramaticpose #expression #facialexpressions #eyes #bookillustration #diagrams #printmaking #line #art #publicdomain
-
Simple Combinations of Upper Lid and Brow (1886), from Delsarte System of Dramatic Expression.
Source: University of Toronto Libraries / Internet Archive
Available to buy as a print.
https://pdimagearchive.org/images/37f8375b-b9b3-4506-b2d7-1174873eae08
#charts #vision #wrinkles #diagram #drama #acting #notation #gesture #furrows #theatre #eyecharts #dramaticpose #expression #facialexpressions #eyes #bookillustration #diagrams #printmaking #line #art #publicdomain
-
Simple Combinations of Upper Lid and Brow (1886), from Delsarte System of Dramatic Expression.
Source: University of Toronto Libraries / Internet Archive
Available to buy as a print.
https://pdimagearchive.org/images/37f8375b-b9b3-4506-b2d7-1174873eae08
#charts #vision #wrinkles #diagram #drama #acting #notation #gesture #furrows #theatre #eyecharts #dramaticpose #expression #facialexpressions #eyes #bookillustration #diagrams #printmaking #line #art #publicdomain
-
The time I used diagramming for success
I had a project idea in my head that seemed too complex to work on until I tried diagramming it.
The idea was a multipurpose CRM-like action/account system thing. I think it might best be described by my first diagram.
I mean, just look at that nonsense. How was I supposed to make a database that handles that? It is the kind of nonsense that gets called “Enterprise” and costs eye-watering piles of cash to keep working.
That was where diagram 2 came in. Having identified groups and entities, it was possible to restructure to something approaching third normal form.
Thus, I made this:
All of that complicated referential business logic boiled down to a fairly simple data logic.
The moral of the story is this: If you have an idea that refuses to be wrestled into a neat or functional shape in your head, write down whatever you have. Lay it out as logically as you can. Often, in the process of writing it down, you will find that the problem can be tamed. The process of writing it down forces you to be clear about everything. Writing it down forces you to process one bit at a time.
The result is often greater clarity.
In my case, I feel ready to start planning the data API layer with what should be some fairly efficient database abstraction.
Sure, I’m going to have a few strange-looking UNION SELECT statements, and more LEFT JOIN and INNER JOIN than normal but I will also have optimised indexes for those selects and joins. Which means that it will not stress my database.
Also, I can use write and read replication to scale my idea.
Please share your thoughts on this with me.
Syndicated to: #DataLayer #Database #diagram #ERD -
The time I used diagramming for success
I had a project idea in my head that seemed too complex to work on until I tried diagramming it.
The idea was a multipurpose CRM-like action/account system thing. I think it might best be described by my first diagram.
I mean, just look at that nonsense. How was I supposed to make a database that handles that? It is the kind of nonsense that gets called “Enterprise” and costs eye-watering piles of cash to keep working.
That was where diagram 2 came in. Having identified groups and entities, it was possible to restructure to something approaching third normal form.
Thus, I made this:
All of that complicated referential business logic boiled down to a fairly simple data logic.
The moral of the story is this: If you have an idea that refuses to be wrestled into a neat or functional shape in your head, write down whatever you have. Lay it out as logically as you can. Often, in the process of writing it down, you will find that the problem can be tamed. The process of writing it down forces you to be clear about everything. Writing it down forces you to process one bit at a time.
The result is often greater clarity.
In my case, I feel ready to start planning the data API layer with what should be some fairly efficient database abstraction.
Sure, I’m going to have a few strange-looking UNION SELECT statements, and more LEFT JOIN and INNER JOIN than normal but I will also have optimised indexes for those selects and joins. Which means that it will not stress my database.
Also, I can use write and read replication to scale my idea.
Please share your thoughts on this with me.
Syndicated to: #DataLayer #Database #diagram #ERD -
The time I used diagramming for success
I had a project idea in my head that seemed too complex to work on until I tried diagramming it.
The idea was a multipurpose CRM-like action/account system thing. I think it might best be described by my first diagram.
I mean, just look at that nonsense. How was I supposed to make a database that handles that? It is the kind of nonsense that gets called “Enterprise” and costs eye-watering piles of cash to keep working.
That was where diagram 2 came in. Having identified groups and entities, it was possible to restructure to something approaching third normal form.
Thus, I made this:
All of that complicated referential business logic boiled down to a fairly simple data logic.
The moral of the story is this: If you have an idea that refuses to be wrestled into a neat or functional shape in your head, write down whatever you have. Lay it out as logically as you can. Often, in the process of writing it down, you will find that the problem can be tamed. The process of writing it down forces you to be clear about everything. Writing it down forces you to process one bit at a time.
The result is often greater clarity.
In my case, I feel ready to start planning the data API layer with what should be some fairly efficient database abstraction.
Sure, I’m going to have a few strange-looking UNION SELECT statements, and more LEFT JOIN and INNER JOIN than normal but I will also have optimised indexes for those selects and joins. Which means that it will not stress my database.
Also, I can use write and read replication to scale my idea.
Please share your thoughts on this with me.
Syndicated to: #DataLayer #Database #diagram #ERD -
The time I used diagramming for success
I had a project idea in my head that seemed too complex to work on until I tried diagramming it.
The idea was a multipurpose CRM-like action/account system thing. I think it might best be described by my first diagram.
I mean, just look at that nonsense. How was I supposed to make a database that handles that? It is the kind of nonsense that gets called “Enterprise” and costs eye-watering piles of cash to keep working.
That was where diagram 2 came in. Having identified groups and entities, it was possible to restructure to something approaching third normal form.
Thus, I made this:
All of that complicated referential business logic boiled down to a fairly simple data logic.
The moral of the story is this: If you have an idea that refuses to be wrestled into a neat or functional shape in your head, write down whatever you have. Lay it out as logically as you can. Often, in the process of writing it down, you will find that the problem can be tamed. The process of writing it down forces you to be clear about everything. Writing it down forces you to process one bit at a time.
The result is often greater clarity.
In my case, I feel ready to start planning the data API layer with what should be some fairly efficient database abstraction.
Sure, I’m going to have a few strange-looking UNION SELECT statements, and more LEFT JOIN and INNER JOIN than normal but I will also have optimised indexes for those selects and joins. Which means that it will not stress my database.
Also, I can use write and read replication to scale my idea.
Please share your thoughts on this with me.
Syndicated to: #DataLayer #Database #diagram #ERD -
A map of the Serpantalon, the hirsute insuffilating viper that Edwige Kenchington calls home.
#map #book #zine #books #zines #BooksWorthReading #ZINEフェス仙台 #chigger #slug #finger #viper #snake #sifilis #syphilis #syphillis #vcr #vhs #90s #90snostalgia #diagram #art #farting #illustration #illustrationart #illustrator #bookstodon #BookStadon
-
In short, we provide a beefed up definition of #DisCoCat where the meaning of words is given not by a #diagram but by a diagram-valued function.
As a concrete example, we take #CharlesSandersPeirce 's existential graphs to go from the #Lambek calculus to logic, i.e. #Montague grammar with diagrams!