Details
-
SkillsPHP, TypeScript, JS, HTML, CSS
-
LocationBelgium, Brussels
Joined devRant on 1/13/2018
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
-
So, you start with a PHP website.
Nah, no hating on PHP here, this is not about language design or performance or strict type systems...
This is about architecture.
No backend web framework, just "plain PHP".
Well, I can deal with that. As long as there is some consistency, I wouldn't even mind maintaining a PHP4 site with Y2K-era HTML4 and zero Javascript.
That sounds like fucking paradise to me right now. 😍
But no, of course it was updated to PHP7, using Laravel, and a main.js file was created. GREAT.... right? Yes. Sure. Totally cool. Gotta stay with the times. But there's still remnants of that ancient framework-less website underneath. So we enter an era of Laravel + Blade templates, with a little sprinkle of raw imported PHP files here and there.
Fine. Ancient PHP + Laravel + Blade + main.js + bootstrap.css. Whatever. I can still handle this. 🤨
But then the Frontend hipsters swoosh back their shawls, sip from their caramel lattes, and start whining: "We want React! We want SPA! No more BootstrapCSS, we're going to launch our own suite of SASS styles! IT'S BETTER".
OK, so we create REST endpoints, and the little monkeys who spend their time animating spinners to cover up all the XHR fuckups are satisfied. But they only care about the top most visited pages, so we ALSO need to keep our Blade templated HTML. We now have about 200 SPA/REST routes, and about 350 classic PHP/Blade pages.
So we enter the Era of Ancient PHP + Laravel + Blade + main.js + bootstrap.css + hipster.sass + REST + React + SPA 😑
Now the Backend grizzlies wake from their hibernation, growling: We have nearly 25 million lines of PHP! Monoliths are evil! Did you know Netflix uses microservices? If we break everything into tiny chunks of code, all our problems will be solved! Let's use DDD! Let's use messaging pipelines! Let's use caching! Let's use big data! Let's use search indexes!... Good right? Sure. Whatever.
OK, so we enter the Era of Ancient PHP + Laravel + Blade + main.js + bootstrap.css + hipster.sass + REST + React + SPA + Redis + RabbitMQ + Cassandra + Elastic 😫
Our monolith starts pooping out little microservices. Some polished pieces turn into pretty little gems... but the obese monolith keeps swelling as well, while simultaneously pooping out more and more little ugly turds at an ever faster rate.
Management rushes in: "Forget about frontend and microservices! We need a desktop app! We need mobile apps! I read in a magazine that the era of the web is over!"
OK, so we enter the Era of Ancient PHP + Laravel + Blade + main.js + bootstrap.css + hipster.sass + REST + GraphQL + React + SPA + Redis + RabbitMQ + Google pub/sub + Neo4J + Cassandra + Elastic + UWP + Android + iOS 😠
"Do you have a monolith or microservices" -- "Yes"
"Which database do you use" -- "Yes"
"Which API standard do you follow" -- "Yes"
"Do you use a CI/building service?" -- "Yes, 3"
"Which Laravel version do you use?" -- "Nine" -- "What, Laravel 9, that isn't even out yet?" -- "No, nine different versions, depends on the services"
"Besides PHP, do you use any Python, Ruby, NodeJS, C#, Golang, or Java?" -- "Not OR, AND. So that's a yes. And bash. Oh and Perl. Oh... and a bit of LUA I think?"
2% of pages are still served by raw, framework-less PHP.32 -
So, now that companies are used to "WFH", maybe we can agree upon a better office for tech companies?
I do actually think the more "ideal" tech company office wouldn't have to be expensive.
It can be smaller. Any tech company worth it's salt should have discovered in the last few months that it's not just devs who can work from home. Sales, support, management — you really don't need to fight your way through highway traffic or cram yourself into a sweaty subway every day.
There's value in having an office. Not everyone can fit a good workspace in their apartment.
But we could at least center it around:
1. A bunch of small, completely soundproof isolation booths, for those who need a focus space, and can't find a silent spot at home.
2. A social lounge space, a communal living room with couches, a bar, creative relaxing stuff, whiteboards, etc. WFH can become depressing even for the most antisocial employees, chilling on a couch with some coworkers to brainstorm ideas or chat about random tech is valuable for building good relationships with your team.
The "open plan office" with rows of desks and monitors, no matter how luxuriously decorated with vertical gardens and hipster desks from reclaimed wood, can go die a fiery painful death.
I either want to work, or socialize.
Open plan offices (and it's even more dystopian suicide-inducing cousin, the cubicle) are like being unable to choose between fucking and a blowjob, so you end up humping a navel.
Oh, and conference rooms, go fuck yourself as well. I want to be able to minimize your ugly face if you plan to talk about company financial reports for 2 hours.2 -
devRant meetup in the Netherlands yesterday was awesome! Hereby a group picture we took.
Thanks for the amazing evening, people!51 -
Sales employee Bob wants a clickable blue button.
Bob tells product owner Karen about his unstoppable desire for clickable blue buttons.
Karen assigns points for potential and impact (how much does a blue button improve Bob's life, how many people like Bob desire blue buttons)
Karen asks the button team how hard it is to build a button. The button team compares the request to a reference button they've built before, and gives an ease score, with higher score being easier (inverse of scrum points).
These three scores are combined to give a priority score. The global buttonbacklog is sorted by priority.
Once every two weeks (a "sprint") the button team convenes, uses the ease scores to assign scrum points. Difficult tasks are broken up into smaller tasks, because there is a scrum point upper limit. They use the average of the last 5 sprints to calculate each developer's "velocity".
The sprint is filled with tasks, from the top of the global button backlog, up to the team's capacity as determined by velocity. Approximate due dates are assigned, Bob is a happy Bob.
What if boss Peter runs into the office screaming "OUR IMPORTANT CLIENT WANTS A FUCKING PINK BUTTON WHICH MAKES HEARTS APPEAR"?
Devs tell boss to shut the fuck up and talk to Karen. Karen has a carefully curated list of button building tasks sorted by priority, can sedate boss with valium so he calms the fuck down until he can make a case for the impact and potential of his pink button.
Karen might agree that Peter's pink button gets a higher priority than Bob's blue button.
But devs are nocturnal creatures, easily disturbed when approached by humans, their natural rhythms thrown out of balance.
So the sprint is "locked", and Peter's pink button appears at the top of the global backlog, from where it flows into the next sprint.
On rare occasions a sprint is broken open, for example when Karen realizes that all of the end users will commit suicide if they don't have a pink heart-spawning button.
In such an event, Peter must make Bob happy (because Bob is crying that his blue button is delayed). And Peter must make the button team of devs happy.
This usually leads to a ritual involving chocolate or even hardware gift certificates to restore balance to the dev ecosystem.23 -
Junior dev requests for sudo access on a server instance for some package installation, gets it, figures out how to open the root shell - never goes back. They do everything on root.
Fast forward to production deployment time, their application won't run without elevated privileges. Sysadmin asks why does the application require elevated privileges. Dev answers, "Because I set it up with root" :facepalm:15 -
--- NVIDIA announces PhysX SDK 4.0, open-sources 3.4 under modified BSD license ---
NVIDIA has announced a new version, 4.0, of PhysX, their physics simulation engine.
Its new features include:
- A "Temporal Gauss-Seidel Solver (TGS)", an algorithm used in this SDK to make things such as robots, character arms, etc. more robust to move around. NVIDIA demonstrates this in the video by making their old version of PhysX, 3.4, seem like an unpredictable mess, the robot demonstrating that version smashing a game of chess.
- New filtering rules for supposedly easier scalability in scenes containing lots of both moving and static objects.
- Faster queries in scenes with actors that have a lot of shapes attached to them, improving performance.
- PhysX can now be more easily used with Cmake-based projects.
In essence, better control over scenes and actors as well as performance improvements are what's new.
Furthermore, NVIDIA has released PhysX version 3.4 under the 3-Clause-BSD-license, except for game console platforms.
As NVIDIA will release the new version on December 20th, it will also be released under the same modified BSD license as PhysX 3.4 is now.
What are your thoughts on NVIDIA making a big move towards the open-source community by releasing PhysX under the BSD license? Feel free to let us know in the comments!
Sources:
https://news.developer.nvidia.com/a...
https://developer.nvidia.com/physx-...
https://github.com/NVIDIAGameWorks/...4 -
--- HTTP/3 is coming! And it won't use TCP! ---
A recent announcement reveals that HTTP - the protocol used by browsers to communicate with web servers - will get a major change in version 3!
Before, the HTTP protocols (version 1.0, 1.1 and 2.2) were all layered on top of TCP (Transmission Control Protocol).
TCP provides reliable, ordered, and error-checked delivery of data over an IP network.
It can handle hardware failures, timeouts, etc. and makes sure the data is received in the order it was transmitted in.
Also you can easily detect if any corruption during transmission has occurred.
All these features are necessary for a protocol such as HTTP, but TCP wasn't originally designed for HTTP!
It's a "one-size-fits-all" solution, suitable for *any* application that needs this kind of reliability.
TCP does a lot of round trips between the client and the server to make sure everybody receives their data. Especially if you're using SSL. This results in a high network latency.
So if we had a protocol which is basically designed for HTTP, it could help a lot at fixing all these problems.
This is the idea behind "QUIC", an experimental network protocol, originally created by Google, using UDP.
Now we all know how unreliable UDP is: You don't know if the data you sent was received nor does the receiver know if there is anything missing. Also, data is unordered, so if anything takes longer to send, it will most likely mix up with the other pieces of data. The only good part of UDP is its simplicity.
So why use this crappy thing for such an important protocol as HTTP?
Well, QUIC fixes all these problems UDP has, and provides the reliability of TCP but without introducing lots of round trips and a high latency! (How cool is that?)
The Internet Engineering Task Force (IETF) has been working (or is still working) on a standardized version of QUIC, although it's very different from Google's original proposal.
The IETF also wants to create a version of HTTP that uses QUIC, previously referred to as HTTP-over-QUIC. HTTP-over-QUIC isn't, however, HTTP/2 over QUIC.
It's a new, updated version of HTTP built for QUIC.
Now, the chairman of both the HTTP working group and the QUIC working group for IETF, Mark Nottingham, wanted to rename HTTP-over-QUIC to HTTP/3, and it seems like his proposal got accepted!
So version 3 of HTTP will have QUIC as an essential, integral feature, and we can expect that it no longer uses TCP as its network protocol.
We will see how it turns out in the end, but I'm sure we will have to wait a couple more years for HTTP/3, when it has been thoroughly tested and integrated.
Thank you for reading!27 -
I keep forgetting people's birthdays and thereby I forget to wish people, and wishing people everyday can become a chore. As somebody once said, if you do something more than once, automate it.
Spent two hours and ended up building a bot that consists of four functions: login, checkIfAuthenticated, postToProfile and getBirthdaysToday using mostly axios and cheerio.
Currently works perfectly and I've been thinking of writing a blog post about it for my 'Automating Your Life' series.
I'll post the link in the comments soon when I'm done with the blog post.40 -
The project where I realized I wanted to go from chemist to pro dev.
I built a flow-chemistry spectrometer with monitoring backend in Haskell.
Spectroscopy is where you add a reagent to a glass tube, it changes color, and by measuring the exact color it tells you how much of something (for example, a toxin) is present in the sample.
I had to do that a lot on factory samples, writing down measurements using pen & paper.
I'm lazy so I decided to do the logical thing: Automate it. I bought a second hand spectrometer, stripped the casing, did a shitload of glassblowing and hooked up tubes to the production pipelines, so I could get samples, mixing them in the correct ratio with reagents in continuous flows using valves.
I ended up using 2 home-crafted arduino-like boards (etching PCBs is fun!).
One to calibrate the mixture against known samples and control solenoid valves to continuously cycle through various reagents and deionized flushing water, the other to record the measurements and send them to a server running a Haskell/Yesod API.
The server collected the information into InfluxDB (A time series database), displaying all data on a graphite dashboard.
Eventually I wrote Haskell plugins for most of the chemistry processes, from pH & temperature measurements to polymer property and pigment tests (they made a lot of printer ink).
Then I was fired because they didn't need chemists anymore, and the code "could be maintained by the intern" (poor guy)...
But I did find out that I loved functional programming, chemistry automation projects, and crafting my own electronics during that time.16 -
I finally made my first production-level bugfix at my new job! 😄 After weeks of training and then being assigned a live bug, I resolved it quickly & elegantly, which helps prove my worth to the team.
Man, it's so gratifying to be making contributions that are going to affect real devices that actual people are using. It seems being a dev with a sense of purpose is nearly as important as enjoying what you do. ☺️ -
The inevitable happened, the user that I've answered tons of questions about freelancing deleted his account, thankfully I took backups and will recreate it [together with a killed joke] in the comments below (should've just webarchived it, meh)
I'll keep adding questions & answers I come across to make this a useful resource for people that want to get into freelancing, want to ask me something in the comments, you name it.
Might compile it into a better searchable resource eventually (some sort of blog with TOC), but right now neither do I have the time nor will to do that.
Wish I could have taken over the link that has been now posted a lot, but every post has an ID and I doubt it's possible, will tag dfox to clarify though and also floydian and devtea, that have been so nice to always post a link to that one rant.52 -
Was looking at a site with my boyfriend on his phone and after a few minutes he set his phone down and started feeling my forehead and cheeks like i had a fever.
I asked him what he was doing and he said "are you sick? You havent spotted anything wrong with this website. You should be raising hell over a menubar or something by now".
....
"Sweetheart this is a Wix site. Its better to just keep my mouth shut this time"5 -
Hopefully we will leave the path of shipping tons of crappy software in increasingly shorter periods of time and come back to thought out, well engineered software that actually matters. I would love that.1
-
Well, it all started off with hardware-level programming involving jumpers and stuff like that... Then came Assembly, which was good.. B, C compilers. Finally came the interpreted languages, and that's where in my opinion the abstraction should've ended. But no, we needed more frameworks, more libraries, even more abstraction! Where does it end? As it seems to be going, I guess that users will have kid toys - no iToys! - for electronics and we'll be programming on with bloated Scratch GUI's. Nothing against Scratch, but that shit ain't proper programming anymore. God I can't wait for the future.
ABSTRACT ALL THE THINGS!!!
Oh and not to mention that all software will be governed in political correctness by some Alex SJW AI shit that became sentient. Not a single programming term will be non-offensive anymore, no matter how hard you try to not offend anyone, or God forbid - don't care about it because you just want to make something that's readable, usable and working!! Terms, UI names for buttons, heck even icons! REMOVE IT BECAUSE IT OFFENDS SOMEONE THAT I DON'T EVEN KNOW JACK SHIT ABOUT!!!18 -
Perhaps more of a wishlist than what I think will actually happen, but:
- Everyone realises that blockchain is nothing more than a tiny niche, and therefore everyone but a tiny niche shuts up about it.
- Starting a new JS framework every 2 seconds becomes a crime. Existing JS frameworks have a big war, until only one is left standing.
- Developing for "FaaS" (serverless, if I must use that name) type computing becomes a big thing.
- Relational database engines get to the point where special handling of "big data" isn't required anymore. Joins across billions of rows doesn't present an issue.
- Everyone wakes up one day and realises that Wordpress is a steaming pile of insecure cow dung. It's never used again, and burns in a fire.9 -
I see it evolving the same way it always has done. The technology will keep changing for the better and the best stuff will emerge on top.
You have a choice to fight the current of new technology that is always flowing by learning and adapting to what comes. If you don't, and you stay stagnant with your chosen tech and skill level, the current will eventually carry away your relevance.
It's natural selection. You have to fight or die. -
My boss is technically my coworker.
I screamed my lungs out after it became clear that he didn't give a shit about employees that bring him money. After snatching all funds from a finished project on time, failing to deliver on the promise about bonuses (it's what I used to motivate employees to deliver the project on time), refusing to buy a new chair to replace the one held together by scotch tape and careful balancing, I decided to quit with maximum damage.
I screamed so that everybody would hear it. That encouraged another guy to get in with quitting, and within 1 month most of the team had quit, leaving the boss with a risk of lawsuits for prepaid contacts not delivered.
Knowing that piece of shit, he probably recovered and is treating other people badly, but at least every single person from the team experienced the biggest jump in careers straight after that.1 -
Friendly reminder for travalers:
You can usually reset your free WiFi time at airport networks by clearing cookies :)10 -
Personlly, Seeing repo commit history in Gource is really mesmerizing and amusing yet scary. especially your own.11
-
Things have been a little too quiet on my side here, so its time for an exciting new series:
practiseSafeHex's new life as a manager.
Episode 1: Dealing with the new backend team
It's great to be back folks. Since our last series where we delved into the mind numbing idiocy of former colleagues, a lot has changed. I've moved to a new company and taken a step up as a Dev manager / Tech lead. Now I know what you are all thinking, sounds more dull and boring right? Well it wouldn't be a practiseSafeHex series if we weren't ...
<audience-shouting>
DEALING! ... WITH! ... IDIOTS!
</audience-shouting>
Bingo! so lets jump right in and kick us off with a good one.
So for the past few months i've been on an on-boarding / fact finding / figuring out this shit-storm, mission to understand more about what it is i'm suppose to do and how to do it. Last week, as part of this, I had the esteemed pleasure of meeting face to face with the remote backend team i've been working with. Lets rattle off a few facts to catch us all up:
- 8 hour time difference to me
- No documentation other than a non-maintained swagger doc
- Swagger is reporting errors and several of the input models are just `Type: String`
- The one model that seems accurate, has every property listed as optional, including what must be the primary key
- Properties go missing and get removed at the drop of a hat and we are never told.
- First email I sent them took 27 days to reply, my response to that hasn't been answered so far 31 days later (new record! way to go team, I knew we could do it!!!)
- I deal directly with 2 of them, the manager and the tech lead. Based on how things have gone so far, i've nick named them:
1) Ass
2) Hole
So lets look at some example of their work:
- I was trying to test the new backend, I saw no data in QA. They said it wouldn't show up until mid day their time, which is middle of the night for us. I said we need data in our timezone and I was told: a) "You don't understand how big this system is" (which is their new catch phrase) b) "Your timezone is not my concern"
- The whole org started testing 2 days later. The next day a member from each team was on a call and I was asked to give an update of how the testing was going on the mobile side. I said I was completely blocked because I can't get test data. Backend were asked to respond. They acknowledged they were aware, but that mobile don't understand how big the system is, and that the mobile team need to come up with ideas for the backend team, as to how mobile can test it. I said we can't do anything without test data, they said ... can you guess what? ... correct "you don't understand how big the system is"
- We eventually got something going and I noticed that only 1 of the 5 API changes due on their side was done. Opened tickets. 2 days later asked them for progress and was told that "new findings" always go to the bottom of the backlog, and they are busy with other things. I said these were suppose to be done days ago. They said you can't give us 2 days notice and expect everything done. I said the original ticket was opened a month a go *sends link* ......... *long silence* ...... "ok, but you don't understand how big the system is, this is a lot of work"
- We were on a call. Product was asking the backend manager (aka "Ass") a question about a slight upgrade to the new feature. While trying to talk, the tech lead (aka "Hole") kept cutting everyone off by saying loudly "but thats not in scope". The question was "is this possible in the future" and "how long would it take", coming from management and product development. Hole just kept saying "its not in scope", until he was told to be quiet by several people.
- An API was sending down JSON with a string containing a message for the user with 2 bits of data inside it. We asked for one of those pieces to also come down as a property as the string can change and we needed it client side. We got that. A few days later we found an edge case and asked for the second piece of data to be a property too. Now keep in mind, they clearly already have access to them in order to make the string. We were told "If you keep requesting changes like this, you are going to delay the release of the backend by up to 2 weeks"
Yes folks, there you have it, the most minuscule JSON modifications, can delay your release by up to 2 weeks ........ maybe I should just tell product, that they don't understand how big the app is, and claim we can't build it on our side? Seems to work for them
Thats all the time we have for today,
Tune in for more, where we'll be looking into such topics as:
- If god himself was an iOS developer ... not
- Why automate when you can spend all day doing it by hand
- Its more time-efficient to just give everything a story point of 5
- Why waste time replying to emails ... when you can do nothing instead
See you all next week,
practiseSafeHex14 -
I am an I.T Admin currently responsible for the URS, Validation, oversight of outsourced development and deployment of a new application for our company...
I've been saying once a week now for 2 fucking months that this thing will be ready to deploy at the end of the week.
With enough technical knowledge I know the hell business people put developers through, the lack of contextual understanding of the Job between the two sides is insane.
(I mean holy shit when you tab through various fields, even that ordering needs to be explicitly programmed.)
I refuse to put the pressure on our devs that I am told too, I cant submit a request and phone ten minutes later to ask if itll be done today, people plan their lives, the devs have other clients and projects... what the mother of fuck makes us so special that they must drop everything.
On top of that all the testing I do over and over and over and over reveals some pretty huge operational risks and I keep making changes so as to not blow up the operations of half our company.
I am not saying my boss is horrible or anything but Holy Hell, most people just can't put themselves in someone else's shoes for five short minutes
I try to please my boss while trying to protect my devs from abuse and sadly it results in me being in the middle of two sides playing tug of war and it is ripping me apart...
Why can't people just be more understanding and communicate and understand better... But don't worry all you beautiful game changing, world improving devs... I will always have your back3 -
Dear assholes of the internet. Next time you publish an article/tutorial/story etc, PUT THE FUCKING PUBLICATION DATE AT THE TOP.
I don’t care about your need to be minimalist, FUCK YOU, INCLUDE THE DATE.18