Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Every time some assholes decide to mix part of the business logic inside the presentation layer.
<body>
<?php
// Let's query the db here...
?>
<body>
<%
/* Hey, I'm a JSP! Why not defining some custom logic here, so nobody will able to debug it? */
%>1 -
rant & question
Last year I had to collaborate to a project written by an old man; let's call him Bob. Bob started working in the punch cards era, he worked as a sysadmin for ages and now he is being "recycled" as a web developer. He will retire in 2 years.
The boss (that is not a programmer) loves Bob and trusts him on everything he says.
Here my problems with Bob and his code:
- he refuses learning git (or any other kind of version control system);
- he knows only procedural PHP (not OO);
- he mixes the presentation layer with business logic;
- he writes layout using tables;
- he uses deprecated HTML tags;
- he uses a random indentation;
- most of the code is vulnerable to SQL injection;
- and, of course, there are no tests.
- Ah, yes, he develops directly on the server, through a SSH connection, using vi without syntax highlighting.
In the beginning I tried to be nice, pointing out just the vulnerabilities and insisting on using git, but he ignored all my suggestions.
So, since I would have managed the production server, I decided to cheat: I completely rewrote the whole application, keeping the same UI, and I said the boss that I created a little fork in order to adapt the code to our infrastructure. He doesn't imagine that the 95% of the code is completely different from the original.
Now it's time to do some changes and another colleague is helping. She noticed what I did and said that I've been disrespectful in throwing away the old man clusterfuck, because in any case the code was working. Moreover he will retire in 2 years and I shouldn't force him to learn new things [tbh, he missed at least last 15 years of web development].
What would you have done in my place?10 -
In reply to:
https://devrant.com/rants/3957914/...
Okay, we must first establish common ground here. What do we understand about "showing"? I understand you probably mean displaying/rendering, more abstractly: "obtaining". Good, now we move on.
What's the point of a front-end? Well, in the 90's that used to be an easy answer: to share information (not even in a user-friendly way, per se). Web 2.0 comes, interaction with the website. Uh-oh, suddenly we have to start minding the user. Web 3.0 comes, ouch, now the front-end is a mini-backend. Even tougher, more leaks etc. The ARPAnet was a solution, a front-end that they had built in order to facilitate research document-sharing between universities. Later, it became the inter(national) net(work).
First there was SGML to structure the data (it's a way of making it 'pretty' in a lexicographical way) and turn it into information (which is what information is: data with added semantics) and later there was HTML to structure it even further, yet we all know that its function was not prettification, but rather structure. Later came CSS, to make it pretty. With its growing popularity, the web started to be used as a publishing device.
source:
https://w3.org/Style/CSS20/...
If we are to solely display JSON data in a pretty way, we may be limiting ourselves to the scenario of rendering pretty web pages using aesthetic languages such as CSS. We must also understand that if we are only focusing on making a website pretty with little to moderate functionality, we aren't really winning. A good website has to be a winner in all aspects, which is why frameworks came into existence, but.. lmao, let's leave that to another discussion.
Now let me recall back my college days.. front-end.. front-end.. heck, even a headset can be a front-end to a pick-order backend. We must think back to the essence, to the abstract. All other things are just implementations of it (yes, the horrendous thousands of Javascript libraries, lol).
So, my college notes say:
"Presentation layer: this is the UI.
In this layer you ask the middle tier for information, which gets that information from a database, which then goes back to middle tier, back to presentation. In the case of the headset, the operators can confirm an order is ready. This is essentially the presentation tier again: you're getting information from the middle tier and 'presenting it' as it were.
The presentation layer is in essence the question: how do I bring my application data to my end users in a platform-and solution-independent way?"
What's JSON? A way to transport data between the middle tier and the presentation tier. Is that what frontend development is? Displaying it in a pretty way? I don't think it is, because 'pretty' is an extra feature of obtaining and displaying data. Do we always have to display data in a pretty way? Not necessarily. We could write a front-end script (in NodeJS perhaps) that periodically fetches certain information from a middle-tier is serves a more functional role rather than a rendering one.
The prettification of data was a historical consequence of the popularity of the web (which is a front-end) (see second paragraph with link). Since the essence of a front-end is to obtain information from the back-end (with stress on obtaining), its presentation is not necessarily a defining characteristic of it, but rather an optional and solution-dependent aspect, a facet.4 -
!rant
Question: I am working on learning MVC/MVP/MVVM/MVPVM and I have read a bunch of articles and done some tutorials but I need some help relating it to n-tier (I think that's what they're called) systems.
I have worked on and I am used to the Presentation (ui) layer > BAL > DAL > DB pattern. How does MVC (and others) relate to the different tiers in a tiered system? I have read that model == DAL, controller == BAL, and view == presentation layer, but I have also read that MVC is meant to extract the presentation layer and that business logic and data logic should be used elsewhere. Can I get some clarity?2 -
SIEM: Security Information and Event Management system
Within a SIEM there is usually a reporting, alerting, and learning framework wherein you perform investigations and threat hunting. Our SIEM is connected to our data lake through a glorified elastic backend.
Today we were figuring out how to get dynamic data that we store in our SIEM to show up in the regular data lake presentation layer. All the solutions only half worked or had barriers to progress that seemed larger than the proposed solution.
So now we're going with the proposed solution: send static data back into the data lake in order to pull it out on the normal frontend with all the enriched info. We're basically turning this thing into a damn feedback loop.
I hate designing solutions within the confines of COTS products. -
#Suphle Rant 7: transphporm failure
In this issue, I'll be sharing observations about 3 topics.
First and most significant is that the brilliant SSR templating library I've eyed for so many years, even integrated as Suphle's presentation layer adapter, is virtually not functional. It only works for the trivial use case of outputting the value of a property in the dataset. For instance, when validation fails, preventing execution from reaching the controller, parsing fails without signifying what ordinance was being violated. I trim the stylesheet and it only works when outputting one of the values added by the validation handler. Meaning the missing keys it can't find from controller result is the culprit.
Even when I trimmed everything else for it to pass, the closing `</li>` tag seems to have been abducted.
I mail project owner explaining what I need his library for, no response. Chat one of the maintainers on Twitter, nothing. Since they have no forum, I find their Gitter chatroom, tag them and post my questions. Nothing. The only semblance of a documentation they have is the Github wiki. So, support is practically dead. Project last commit: 2020. It's disappointing that this is how my journey with them ends. There isn't even an alternative that shares the same philosophy. It's so sad to see how everybody is comfortable with PHP templating syntax and back end logic entagled within their markup.
Among all other templating libraries, Blade (which influenced my strong distaste for interspersing markup and PHP), seems to be the most popular. First admission: We're headed back to the Blade trenches, sadly.
2nd Topic: While writing tests yesterday, I had this weird feeling about something being off. I guess that's what code smell is. I was uncomfortable with the excessive amount of mocking wrappers I had to layer upon SUT before I can observe whether the HTML adapter receives expected markup file, when I can simply put a `var_dump` there. There's a black-box test for verifying the output but since the Transphporm headaches were causing it to fail, I tried going white-box. The mocking fixture was such a monstrosity, I imagined Sebastian Bergmann's ghost looking down in abhorrence over how much this Degenerate is perverting and butchering his creation.
I ultimately deleted the test travesty but it gave rise to the question of how properly designed system really is. Or, are certain things beyond testing white box? Are there still gaps in the testing knowledge of a supposed testing connoisseur? 2nd admission.
Lastly, randomly wanted to tweet an idea at Tomas Votruba. Visited his profile, only to see this https://twitter.com/PovilasKorop/.... Apparently, Laravel have implemented yet another feature previously only existing in Suphle (or at the libraries Arkitekt and Deptrac). I laughed mirthlessly as I watch them gain feature-parity under my nose, when Suphle is yet to be launched. I refuse to believe they're actually stalking Suphle
3
Top Tags
Weekly Rant
View