7 ms·

Yeah, I really can't tell if it's satire. Especially things like this: > I’m not smart enough to figure out how to transform data between different layers of t

by jamil7 3y ago

Yeah, I really can't tell if it's satire. Especially things like this: > I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer. OK, well then you might need to gather a little more work experience and meet the repercussions of decisions like this one. Or maybe the OP is a contractor and never has to deal with the repercussions of their actions.

HideousKojima 3y ago
And they'll also run into major liability issues when they leak customer credit card information, SSN, or something similar because they have a single class that represents the table in the database and they use it in both the frontend and backend.
- nerdchum 3y ago
  how does the "structure" of the data have anything to do with leaking information? Seems like data protection occurs way lower in the stack like https and encryption at rest.
  - Scalestein 3y ago
    I'm guessing they are thinking of a scenario where SELECT * FROM User_Details gets sent directly to the front end. So even if all you are displaying is the users name or initials you would still be sending things like SSN and credit card number to the front end
    - nerdchum 3y ago
      Sanitizing your inputs is a string issue not a data structure issue. Sanitizing your inputs has been known about for literally almost half a century that should just be default for developers at this point.
      - waboremo 3y ago
        >Sanitizing your inputs has been known about for literally almost half a century that should just be default for developers at this point. Except if you're a "stupid programmer", in which such defaults are irrelevant to you. In such cases, one can only hope they're relying on tooling that sanitizes as much as possible for them.
  - ang_cire 3y ago
    Because of things like mass assignment or IDOR, or injection attacks, presumably. Handing data from the user (untrusted input) directly to the backend unchanged is going to in 99.9999999% of cases also mean it's unchecked. "I'm not smart enough to bother sanitizing my input, or to learn about stuff that's someone else's job like security" would fit right into this "manifesto".
    - nerdchum 3y ago
      Sanitizing data is string based not data structure based though.
      - ang_cire 3y ago
        Well first off, that's not correct anyways; type-conformancy is a very valid and important part of data sanitization. E.g. does the SSN consist of 3 valid integers split on dashes? If not, it ain't a proper SSN. Catching that typeError is much safer than trying to roll regex or character allow/blocklists. But also, the manifesto never mentions data structures. It says > I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer. Transforming data means actually changing the data, not the data structure that houses it. The author is explicitly talking about making changes to the data itself.
        nerdchum 3y ago
        You shouldnt have to "transform" the data though. You should validate the data and sanitize the data...but if youre transforming data youre headed into a state management nightmare. State management is the number one enemy and other than sanitizing and validating both the data and structure should be considered mostly immutable.
        ang_cire 3y ago
        You absolutely may need and want to transform data. You don't want to store code unmodified in a database; that's how you end up with SSTI or stored XSS. You encode special characters in a simple, reversible way (as one example). Similarly, you don't store passwords untransformed in a db, you hash them. That's a transform. There are tons of examples like this.
  - TheOtherHobbes 3y ago
    Data protection also happens at a much lower level. If you're running your binary blob on a server with no firewall you will be hammered with constant root hacks. https and REST encryption will be irrelevant. Even worse, you may be running a mail server on the same machine.
    - nerdchum 3y ago
      > hammered with constant root hacks. That happens to every server exposed to the internet. Unless there is a targeted ddos event its usually on the level of a query or two per second AT MOST or so. Its something most people don't worry about because theres no way around it. If you need ddos protection you put the server behind cloudflare or something like it. Its totally fine to raw dog the internet without a firewall in my opinion if the server only has a single web server that you keep updated and sanitize your inputs. Running other services on the same server without a firewall becomes horrible though youre right. lol
nerdchum 3y ago
Transforming state data between different layers of the system if done wrong is one of the biggest nightmares in my opinion you could have.
- jamil7 3y ago
  I think the reality is that neither of those outcomes are desirable and your statement doesn't do anything to support the OPs case. Both are wrong.
  - nerdchum 3y ago
    Less state changes the better. Managing state is the number one enemy on software.
    - bluefirebrand 3y ago
      I agree wholeheartedly. I don't understand why everyone insists on repackaging the same data over and over. Store it in one format in the database. Read from the database and transform it. Package that into a TO object and send it over the wire. Receive the TO object and repackage it into your local context Take the local context and repackage a bunch of parts of it into each view model as necessary. Everyone just wants to bundle up data and throw it over a wall instead of working together to engineer end to end.
      - aleksiy123 3y ago
        Because you don't want couple your data model with your public contract. it allows you to change them independently. When it comes time to change your data model you can't without bubbling it all the way through the to the public API which may not be desirable. Repackaging the data at every level means you only have to change the transformation at one of those levels. For small projects this isn't a big deal. But if you are working on a large project with multiple teams you have public contracts at multiple levels. You don't want to wade through 10 layers and 10 teams of changes because you change the way you store and compute some attribute.
rvense 3y ago
I think what they're really trying to say is "we can start out with this and in a lot of cases we won't ever have to change it".
- hsn915 3y ago
  No that's not what I'm saying.
  - rvense 3y ago
    Haha, OK! Well, sorry, then.
jerf 3y ago
That's a particularly weird one in light of starting out with "I only use statically typed languages", because it's basically trivial in a statically typed language. You have "type UIData", "type StorageData", and functions/methods to convert back and forth between them. Those functions/methods may need additional parameters, which will be documented by the mere act of calling for them in the function signature. You take the right type in the right place and the language does the rest, basically. Statically-typed languages are so good at this that even refactoring it after the fact is trivial; potentially tedious and lengthy, but generally trivial. You just create the new type you need, put it in one place in the code where it belongs, then start compiling the code and fixing the errors it flags. Repeat until you've converted all uses of the old type to the new type or performed the correct conversion. It'll probably just work the next time you run it. You don't anything even remotely as strong as Haskell to have an "It Just Works when I compile it" moment. In dynamically-typed languages this is a nightmare, and this is one of the significant reasons I've stopped using them. Finding a bug six months to six years later from some attempt at this and finding a place that used the old type incorrectly when it was getting the new type, or because the programmer thought they were getting one but in fact got the other, or my favorite, the code is actually called with both types and nobody noticed until way too late... it's just something I've had enough of.
- hsn915 3y ago
  But, _what_ is the point of using a different layout/structure for storage vs the UI layer? Remember I'm a 0.5x developer. If I have to write code to transform data for every kind of entity/object I need to store and have a UI to view and edit, that's way too much. I'm already very slow. No need to slow me down further by telling me I have to write so much extra code that does no useful work.
  - DaiPlusPlus 3y ago
    > the point of using a different layout/structure for storage vs the UI layer? By way of example, I'll point to the classic example of a New User form UI: that UI will need 2 password inputs (one for the password, the other for the "confirm password") - but your User object/schema/DB-table won't have two separate string password fields - it'll have a single binary/byte[] salted-password-hash field, and you certainly must never show that in the UI. As for your (reasonable!) concerns about having to write-out repetitive types/models that all share similar (though hardly ever identical) data/fields/shape: I agree it's tedious, but that's what we have scaffolding-tools for (granted, I often end-up having to write my own scaffolding and templaying tools...), so for a simple CRUD application just design your database and have the scaffolding tools take care of the rest, including stubbing-out a functional UI (and this is why Ruby-on-Rails was huge when it first came out: it took-away all of the drudgery in CRUD web-applications - but then all the other frameworks/platforms improved their scaffolding-stories and RoR is certainly less attractive in comparison now. ----- Oh, and of course, ChatGPT et al. is also incredibly effective at scaffolding entire solutions from scratch, e.g. from last month: https://bit.kevinslin.com/p/leveraging-gpt-4-to-automate-the https://bit.kevinslin.com/p/leveraging-gpt-4-to-automate-the
stakhanov 3y ago
> contractor and never has to deal with the repercussions of their actions. This doesn't match my experience of contracting. Not caring about code quality and then leaving others holding the bag of sh*t is frequently what "ladder climbers" do, and those are, by definition, on payroll rather than contractors. For a contractor, there is no ladder to climb, but willingness to get one's hands dirty is definitely part of the job description. Contractors are quite frequently the people who are brought in at extra expense to maintain mission-critical infrastructure when the employee who made it is no longer at the firm, or has moved on to different responsibilities. After having gone through several contracts, a typical contractor will often have a lot more experience with different coding practices and their respective outcomes and a deeper appreciation of good engineering.
- DaiPlusPlus 3y ago
  > For a contractor, there is no ladder to climb, The trick is to refuse to adopt the job-title "contractor" - simply refer to oneself as a "consultant" - it goes a long way. Fun-fact: there's no rule against contractors/consultants earning equity in their clients' projects either: apparently I can artificially raise my hourly-rate by 20% during the post-interview negotiations, then sweet-talk the client into letting me have token equity in exchange for a 16% pay-cut. Simply do this for every small gig you get and eventually it works out as a pretty-nice personal-ladder to early-retirement. ...not that I want to retire, really - the idea terrifies me because I simply can't do anything except work :/
- JohnFen 3y ago
  Yes, my experience being a contractor largely backs this up. Also, remember another possible reasons why a company might hire a contractor: to have someone to blame for a project they know is failing. One of my favorite things about contract work is that it's time-limited. This means that I can be 100% honest about bad dev processes, bad code, bad management, etc., because I won't have to worry about angry managers making my life miserable for any longer than the remainder of my contract period. I can't count the number of times I've spoken up about something terrible, only to have the permanent devs privately tell me later "I'm so happy you said that. I've been wishing I could bring that up for years"
ehutch79 3y ago
or the field is "is_rspts_field" and no one will tell them what that means.

by jamil7 3y ago

HideousKojima 3y ago

And they'll also run into major liability issues when they leak customer credit card information, SSN, or something similar because they have a single class that represents the table in the database and they use it in both the frontend and backend.

nerdchum 3y ago
how does the "structure" of the data have anything to do with leaking information? Seems like data protection occurs way lower in the stack like https and encryption at rest.
- Scalestein 3y ago
  I'm guessing they are thinking of a scenario where SELECT * FROM User_Details gets sent directly to the front end. So even if all you are displaying is the users name or initials you would still be sending things like SSN and credit card number to the front end
  - nerdchum 3y ago
    Sanitizing your inputs is a string issue not a data structure issue. Sanitizing your inputs has been known about for literally almost half a century that should just be default for developers at this point.
    - waboremo 3y ago
      >Sanitizing your inputs has been known about for literally almost half a century that should just be default for developers at this point. Except if you're a "stupid programmer", in which such defaults are irrelevant to you. In such cases, one can only hope they're relying on tooling that sanitizes as much as possible for them.
- ang_cire 3y ago
  Because of things like mass assignment or IDOR, or injection attacks, presumably. Handing data from the user (untrusted input) directly to the backend unchanged is going to in 99.9999999% of cases also mean it's unchecked. "I'm not smart enough to bother sanitizing my input, or to learn about stuff that's someone else's job like security" would fit right into this "manifesto".
  - nerdchum 3y ago
    Sanitizing data is string based not data structure based though.
    - ang_cire 3y ago
      Well first off, that's not correct anyways; type-conformancy is a very valid and important part of data sanitization. E.g. does the SSN consist of 3 valid integers split on dashes? If not, it ain't a proper SSN. Catching that typeError is much safer than trying to roll regex or character allow/blocklists. But also, the manifesto never mentions data structures. It says > I’m not smart enough to figure out how to transform data between different layers of the system, so I just don’t. I use the same represetnation in the UI layer and the storage layer. Transforming data means actually changing the data, not the data structure that houses it. The author is explicitly talking about making changes to the data itself.
      - nerdchum 3y ago
        You shouldnt have to "transform" the data though. You should validate the data and sanitize the data...but if youre transforming data youre headed into a state management nightmare. State management is the number one enemy and other than sanitizing and validating both the data and structure should be considered mostly immutable.
        ang_cire 3y ago
        You absolutely may need and want to transform data. You don't want to store code unmodified in a database; that's how you end up with SSTI or stored XSS. You encode special characters in a simple, reversible way (as one example). Similarly, you don't store passwords untransformed in a db, you hash them. That's a transform. There are tons of examples like this.
- TheOtherHobbes 3y ago
  Data protection also happens at a much lower level. If you're running your binary blob on a server with no firewall you will be hammered with constant root hacks. https and REST encryption will be irrelevant. Even worse, you may be running a mail server on the same machine.
  - nerdchum 3y ago
    > hammered with constant root hacks. That happens to every server exposed to the internet. Unless there is a targeted ddos event its usually on the level of a query or two per second AT MOST or so. Its something most people don't worry about because theres no way around it. If you need ddos protection you put the server behind cloudflare or something like it. Its totally fine to raw dog the internet without a firewall in my opinion if the server only has a single web server that you keep updated and sanitize your inputs. Running other services on the same server without a firewall becomes horrible though youre right. lol

nerdchum 3y ago

Transforming state data between different layers of the system if done wrong is one of the biggest nightmares in my opinion you could have.

jamil7 3y ago
I think the reality is that neither of those outcomes are desirable and your statement doesn't do anything to support the OPs case. Both are wrong.
- nerdchum 3y ago
  Less state changes the better. Managing state is the number one enemy on software.
  - bluefirebrand 3y ago
    I agree wholeheartedly. I don't understand why everyone insists on repackaging the same data over and over. Store it in one format in the database. Read from the database and transform it. Package that into a TO object and send it over the wire. Receive the TO object and repackage it into your local context Take the local context and repackage a bunch of parts of it into each view model as necessary. Everyone just wants to bundle up data and throw it over a wall instead of working together to engineer end to end.
    - aleksiy123 3y ago
      Because you don't want couple your data model with your public contract. it allows you to change them independently. When it comes time to change your data model you can't without bubbling it all the way through the to the public API which may not be desirable. Repackaging the data at every level means you only have to change the transformation at one of those levels. For small projects this isn't a big deal. But if you are working on a large project with multiple teams you have public contracts at multiple levels. You don't want to wade through 10 layers and 10 teams of changes because you change the way you store and compute some attribute.

rvense 3y ago

I think what they're really trying to say is "we can start out with this and in a lot of cases we won't ever have to change it".

hsn915 3y ago
No that's not what I'm saying.
- rvense 3y ago
  Haha, OK! Well, sorry, then.

jerf 3y ago

That's a particularly weird one in light of starting out with "I only use statically typed languages", because it's basically trivial in a statically typed language. You have "type UIData", "type StorageData", and functions/methods to convert back and forth between them. Those functions/methods may need additional parameters, which will be documented by the mere act of calling for them in the function signature. You take the right type in the right place and the language does the rest, basically. Statically-typed languages are so good at this that even refactoring it after the fact is trivial; potentially tedious and lengthy, but generally trivial. You just create the new type you need, put it in one place in the code where it belongs, then start compiling the code and fixing the errors it flags. Repeat until you've converted all uses of the old type to the new type or performed the correct conversion. It'll probably just work the next time you run it. You don't anything even remotely as strong as Haskell to have an "It Just Works when I compile it" moment. In dynamically-typed languages this is a nightmare, and this is one of the significant reasons I've stopped using them. Finding a bug six months to six years later from some attempt at this and finding a place that used the old type incorrectly when it was getting the new type, or because the programmer thought they were getting one but in fact got the other, or my favorite, the code is actually called with both types and nobody noticed until way too late... it's just something I've had enough of.

hsn915 3y ago
But, _what_ is the point of using a different layout/structure for storage vs the UI layer? Remember I'm a 0.5x developer. If I have to write code to transform data for every kind of entity/object I need to store and have a UI to view and edit, that's way too much. I'm already very slow. No need to slow me down further by telling me I have to write so much extra code that does no useful work.
- DaiPlusPlus 3y ago
  > the point of using a different layout/structure for storage vs the UI layer? By way of example, I'll point to the classic example of a New User form UI: that UI will need 2 password inputs (one for the password, the other for the "confirm password") - but your User object/schema/DB-table won't have two separate string password fields - it'll have a single binary/byte[] salted-password-hash field, and you certainly must never show that in the UI. As for your (reasonable!) concerns about having to write-out repetitive types/models that all share similar (though hardly ever identical) data/fields/shape: I agree it's tedious, but that's what we have scaffolding-tools for (granted, I often end-up having to write my own scaffolding and templaying tools...), so for a simple CRUD application just design your database and have the scaffolding tools take care of the rest, including stubbing-out a functional UI (and this is why Ruby-on-Rails was huge when it first came out: it took-away all of the drudgery in CRUD web-applications - but then all the other frameworks/platforms improved their scaffolding-stories and RoR is certainly less attractive in comparison now. ----- Oh, and of course, ChatGPT et al. is also incredibly effective at scaffolding entire solutions from scratch, e.g. from last month: https://bit.kevinslin.com/p/leveraging-gpt-4-to-automate-the https://bit.kevinslin.com/p/leveraging-gpt-4-to-automate-the

stakhanov 3y ago

> contractor and never has to deal with the repercussions of their actions. This doesn't match my experience of contracting. Not caring about code quality and then leaving others holding the bag of sh*t is frequently what "ladder climbers" do, and those are, by definition, on payroll rather than contractors. For a contractor, there is no ladder to climb, but willingness to get one's hands dirty is definitely part of the job description. Contractors are quite frequently the people who are brought in at extra expense to maintain mission-critical infrastructure when the employee who made it is no longer at the firm, or has moved on to different responsibilities. After having gone through several contracts, a typical contractor will often have a lot more experience with different coding practices and their respective outcomes and a deeper appreciation of good engineering.

DaiPlusPlus 3y ago
> For a contractor, there is no ladder to climb, The trick is to refuse to adopt the job-title "contractor" - simply refer to oneself as a "consultant" - it goes a long way. Fun-fact: there's no rule against contractors/consultants earning equity in their clients' projects either: apparently I can artificially raise my hourly-rate by 20% during the post-interview negotiations, then sweet-talk the client into letting me have token equity in exchange for a 16% pay-cut. Simply do this for every small gig you get and eventually it works out as a pretty-nice personal-ladder to early-retirement. ...not that I want to retire, really - the idea terrifies me because I simply can't do anything except work :/
JohnFen 3y ago
Yes, my experience being a contractor largely backs this up. Also, remember another possible reasons why a company might hire a contractor: to have someone to blame for a project they know is failing. One of my favorite things about contract work is that it's time-limited. This means that I can be 100% honest about bad dev processes, bad code, bad management, etc., because I won't have to worry about angry managers making my life miserable for any longer than the remainder of my contract period. I can't count the number of times I've spoken up about something terrible, only to have the permanent devs privately tell me later "I'm so happy you said that. I've been wishing I could bring that up for years"

ehutch79 3y ago

or the field is "is_rspts_field" and no one will tell them what that means.