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
Search - "the code thing isn't really possible"
-
We're using a ticket system at work that a local company wrote specifically for IT-support companies. It's missing so many (to us) essential features that they flat out ignored the feature requests for. I started dissecting their front-end code to find ways to get the site to do what we want and find a lot of ugly code.
Stuff like if(!confirm("blablabla") == false) and whole JavaScript libraries just to perform one task in one page that are loaded on every page you visit, complaining in the js console that they are loaded in the wrong order. It also uses a websocket on a completely arbitrary port making it impossible to work with it if you are on a restricted wifi. They flat out lie about their customers not wanting an offline app even though their communications platform on which they got asked this question once again got swarmed with big customers disagreeing as the mobile perofrmance and design of the mobile webpage is just atrocious.
So i dig farther and farthee adding all the features we want into a userscript with a beat little 'custom namespace' i make pretty good progress until i find a site that does asynchronous loading of its subpages all of a sudden. They never do that anywhere else. Injecting code into the overcomolicated jQuery mess that they call code is impossible to me, so i track changes via a mutationObserver (awesome stuff for userscripts, never heard of it before) and get that running too.
The userscript got such a volume of functions in such a short time that my boss even used it to demonstrate to them what we want and asked them why they couldn't do it in a reasonable timeframe.
All in all I'm pretty proud if the script, but i hate that software companies that write such a mess of code in different coding styles all over the place even get a foot into the door.
And that's just the code part: They very veeeery often just break stuff in updates that then require multiple hotfixes throughout the day after we complain about it. These errors even go so far to break functionality completely or just throw 500s in our face. It really gives you the impression that they are not testing that thing at all.
And the worst: They actively encourage their trainees to write as much code as possible to get paid more than their contract says, so of course they just break stuff all the time to write as much as possible.
Where did i get that information you ask? They state it on ther fucking career page!
We also have reverse proxy in front of that page that manages the HTTPS encryption and Let's Encrypt renewal. Guess what: They internally check if the certificate on the machine is valid and the system refuses to work if it isn't. How do you upload a certificate to the system you asked? You don't! You have to mail it to them for them to SSH into the system and install it manually. When will that be possible you ask? SOON™.
At least after a while i got them to just disable the 'feature'.
While we are at 'features' (sorry for the bad structure): They have this genius 'smart redirect' feature that is supposed to throw you right back where you were once you're done editing something. Brilliant idea, how do they do it? Using a callback libk like everyone else? Noooo. A serverside database entry that only gets correctly updated half of the time. So while multitasking in multiple tabs because the performance of that thing almost forces you to makes it a whole lot worse you are not protected from it if you don't. Example: you did work on ticket A and save that. You get redirected to ticket B you worked on this morning even though its fucking 5 o' clock in the evening. So of course you get confused over wherever you selected the right ticket to begin with. So you have to check that almost everytime.
Alright, rant over.
Let's see if i beed to make another one after their big 'all feature requests on hold, UI redesign, everything will be fixed and much better'-update.5 -
I just installed Opera Mini on my PSP. That alone isn't very exciting on its own, although I am stoked that my website does in fact render on a device from 2009. With the helpful guidance of a laptop from 2004 that's doing the hotspot duties for this thing.
No, what really got me stoked is that Opera still supports these old platforms, and how small they managed to make it. The .jar file for Opera Mini 4.5 is ~800kB large. There's a .jad file as well but it's negligible in size and seems to be a signature of sorts.
Let that sink in for a moment. This entire web browser is 800kB. Firefox meanwhile consistently consumes 800 MEGABYTES.. in MEMORY. So then, I went to think for a moment, how on earth did they manage to cram an entire functioning web browser in 800kB? Hell, what makes up a web browser anyway?
The answer to that question I got to is as follows. You need an engine to render the web page you receive. You need a UI to make the browser look nice. And finally you need a certificate store to know which TLS certificates to trust. And while probably difficult to make, I think it should be possible to do in 800k. Seriously, think about it. How would you go *make* a web browser? Because I've already done that in the past.
Earlier I heard that you need graphics, audio, wasm, yada yada backends too.. no. Give your head a shake. Graphics are the responsibility of the graphics driver. A web browser shouldn't dabble with those at all. Audio, you connect to PulseAudio (in Linux at least) and you're done. Hell I don't even care about ALSA or OSS here. You just connect to the stuff that does that job for you. And WebAssembly.. God I could rant about that shit all day. How about making it a native application? Not like actual Assembly is used for BIOS and low-level drivers. And that we already have a better language for the more portable stuff called C.
Seriously, think about it. Opera - a reputable browser vendor - managed to do it in 800kB on a 12 year old device. Don't go full wank on your framework shit on the comments. And don't you fucking dare to tell me that there's more to it. They did it for crying out loud. Now you take a look at your shitpile for JS code and refactor that shit already. Thank you.21 -
@Owenvii made a post over at (https://devrant.com/rants/2359774/...) and I want to write a proper response.
The biggest thing you have to look out for as a new dev is the jobs which you accept to begin with.
This isn't minimum wage no more, this is "big league", well, maybe not apple or google big league, but it's not $9.25 an hour either.
Basically you don't want to work anywhere where 1. your labor will be treated as a highly disposable commodity. 2. where the hiring manager doesn't know how to do the job themselves.
The best thing you can do is, if you're new, and just breaking through (and even if you're not), is ask them common questions and problems/solutions that crop up doing the work. If they can answer intelligently that tells you the company values competence (maybe), enough to put someone in place who will know ability from bullshit, merit from mediocrity, and who understands the process of progressing from junior dev to a more involved role.
It also means they are incentivized to hire people who know what they're doing because the training cost of new hires is lowered when they hire people who are actually competent or capable of learning.
Remember, an interview isn't just them learning about you, it's your opportunity to interview *them* and boy, you'll be making a BIG mistake if you don't.
Ideally you want them to ask you to pair program a problem. If your solution is better than theirs then they aren't sending their best to do interviews, and it tells you the company doesn't fire incompetents. The interviewers response can tell you a lot too, if they critique your work, or suggest improvements, and especially if they explain their thinking, that is an amazing response to look for, it says the company values mentorship and *actual* teamwork (not the corporate lingo-bingo 'teamwork' that we sometimes see idolized on posters like so much common dogma).
Most importantly, get them to talk about their work and their team. If they're a professional, it'll be really difficult to pry anything negative about their co-workers out of them, but if they're loose-lipped and gossipy thats a VERY bad sign, regardless of what they have to say.
Ask to take a tour and do a meet n' greet of who you will be working with. If they say no, then it's no thank you to a job offer. You want to take every opportunity to get to know everyone there, everyone you'll be working with, as much as possible--because you'll be spending a LOT of time with these people and you want to rule out any place that employs 'unfireable' toxic assholes, sociopath executives, manipulative ladder climbing narcissists, and vicious misery-loving psychopathic coworkers as quick as possible. This isn't just one warning flag to look out for, it's the essential one. You're looking for the proper *workplace culture*, not the cheesy startup phrase of "workplace culture", but the actual attitudes of the team and the interpersonal dynamics.
Life is really short, and a heart attack at 25 from dipshit coworkers and workplace grief can and will destroy your health, if not your sanity, the older you get.
Trust and believe me when I say no paycheck is too grand to deal with some useless, smarmy, manipulative, or borderline motherfuckers at work constantly. You'll regret it if you do. Don't do it. Do you fucking do it. Just don't.
Take my words to heart and be weary of easy job offers. I'm not saying don't take a good offer that lands in your lap, I AM saying do some investigating and due diligence or the consequences are on you.1 -
When you're developing it's very well advised to run your software locally in an environment as much as possible matching the real environment.
So for example, if you're running linux on production then you also run it locally to run your code.
Here's where people need to shut the fuck up:
No, mac is not good for linux development. Not unless portability is already a concern that you have and even then it might be counter productive. So many times when people say this, portability isn't not a concern. What runs on servers is up to them.
If your servers are going to be centos, then you develop with centos. Not with debian, gentoo, ubuntu, maxosx, etc.
Even different linux distros are a headache for portability when it's just to support a few desktops for development so don't think that macosx is going to cut it. It might not be as radical a difference as between windows and linux traditionally is but it's still not good for "linux" development. I don't think people making that statement really know what linux is now how different distributions work.
What you use for your graphical operating system doesn't matter to much but when you run your code then there's a simple solution.
Another thing people need to shut up about. It's not docker, unless you're already in Linux where docker is one of many options such as chroot or lxc.
This question always comes up, how do you developer for linux in windows? No it's not docker it's virtual machine.
It's that simple. You download the ISO for the distro you want and then install it on a VM. What does docker for windows do? It runs a linux VM that runs docker.
This may come as a great shock to developers around the world but it is possible to run linux in a VM and then any linux application your want including docker.
Another option is to shove a box in the corner, install what you need on it, share the file system and have people use that to run their code. It really is that easy.6 -
promises in JavaScript have really spoiled me
it's the most optimal way to do async without leaving much on the table
there's a promises library in rust and the guy who wrote it says it sucks because it spawns new thread every time you execute a bunch of promises
and I finally, through my fogged brain, managed to get the bright idea to write what I want to make in rust in JavaScript and holy hell it's sexy to work with promises. there's no performance left on the table. you do things as fast as possible
but if I take this JavaScript usability code I made and make it possible syntax-wise in rust I don't see how I would be able to do it without starting new operating system threads every time I execute any promises (or set)
I can take the overhead hit but this sounds retarded
and this isn't even touching upon how in rust everything needs to have a predetermined data type. so you can do lambdas and capture variables and send in variables into a thread that way, but to return the return object must be a consistent type (synchronizing the order data was sent in to the data sent out aside, haven't written that yet should be fine though)
which is fine if you are making a threadpool and it'll all be returning one data type
but this means you can't reuse a threadpool you made elsewhere in the program
the only thing that could fix async is to literally be compiler-enabled. it would have to work like generics and automatically make an enum of every type that can return, and only then could you re-use the threadpool23 -
I'm shitting there hammering out some code butchering some real problems when I suddenly realise I'm surrounded. I look around and yes it's the bloody committee.
The committee is what I call the rest of the department and it is dominated by the old guard which comprises of the programmers that have been around for longer.
None of the old guard can program particularly well but because they had been around the longest they'd all grown senior. The committee had free reign but anyone else doing anything differently has to get approval from the committee.
The only way to code otherwise was to copy and paste existing code then to primarily rename things. If anyone did anything that hadn't been seen before then it would have to be approved by the committee. Individual action was not permitted unless you were old guard.
I swept my headphones away expecting it to be something unimportant. It was.
First things first they announce. We're going to add extraneous commas to the last element of all possible lists separated by comma including parameters or so they say. Ask but why so I do.
Because the language now supports it. They added support for it so it must be the right way someone proclaimed. Does it? I didn't realise we were waiting for it. Why do we want it though?
Didn't you hear? It's all over the blogosphere. It massively improves merge requests. But how I ask?
Five minutes later I grow tired of the chin stroking, elbow harnessing, slanted gazes into the yonder and occasionally hearing maybe its because and ask if they mean when you for example add an element the last element registers as changed from adding a comma. Turns out that's all it is.
How often do we see that tiny distraction and isn't it pointless to make the code ugly just for a tiny transient reduction in diff noise I ask. Everyone's stumped. This went on and on and got worse and worse. But it makes moving things around easy half of them say in unison like the bunch of slobs that they are. I mean really. It doesn't make expanding and contracting statements from multiline to single line easy and it's such a stupid thing. Is that all they do all day? Move multi-line method parameters up and down all day? If their coding conventions weren't totally whack they wouldn't have so many multiline method prototypes with stupid amounts of parameters with stupidly long types and names. They all use the same smart IDE which can also surely handle fixing the last comma and why is that even a concern given all the other outrageously verbose and excessive conventions for readability?
But you know what, who cares, fine, whatever. Lets put commas all over the shop and then we can all go to the pub and woo the ladies with how cool and trendy we are up to date with all the latest trends and fashions then we go home with ten babes hanging off each arm and get so laid we have to take a sick day the following to go to the STD clinic. Make way for we are conformists.
But then someone had to do it. They had to bring up PSR. Yes, another braindead committee that produces stupid decisions. Should brackets be same line or next line, I know, lets do both they decided. Now we have to do PSR and aren't allowed to use sensible conventions.
But why, I ask after explaining it's actually quite useful as a set of documents we can plagiarise as a starting point but then modify but no, we have to do exactly what PSR says. We're all too stupid apparently you see. Apparently we're not on their level. We're mere mortals. The reason or so I'm told, is so that anyone can come in and is they know PSR coding styles be able to read and write the code. That's not how it works. If you can't adjust to a different style, a more consistent style, that's not massively bizarre or atypical but rather with only minor differences from standard styles, you're useless. That's not even an argument, it's a confession that you've got a lump of coal where your brain's supposed to be.
Through all of this I don't really care because I long ago just made my own code generators or transpilers that work two ways and switch things between my shit and their shit but share my wisdom anyway because I'm a greedy scumbag like that.
Where the shit really hit the fan is that I pointed out that PSR style guide doesn't answer all questions nor covers all cases so what do we do then. If it's not in PSR? Then we're fucked.4 -
HTML Writers Guidelines
When designing your web site you want to make the visiting experience as enjoyable as possible and at the same time make it so that if the site needs to be changed in any way, the changes are not too difficult to make. You want the look to be as appealing as possible for all browsers and also make the site accessible to users with disabilities. In order to accomplish all this there are some general guidelines when creating your HTML code.
1. The first thing that will really make your life easier is through the use of Cascading Style Sheets (CSS) - CSS is used to maintain the look of the document such as the fonts, margins and color. HTML directly on the page is not a good choice to handle these aspects because if say, the font color you are using for certain paragraphs needs to be changed from blue to red, you would have to go in and change each color tag manually. By using CSS you can designate the color for each of those paragraphs just once in the CSS file. That way if you have to change the font color from blue to red you make one change instead of the countless number of changes you might have to make, especially if your web site contains hundreds of pages. This is a big time saver and a must for all professionally designed web sites.
2. Don't use the FONT tag directly in your HTML code - This becomes a problem when using some cheap authoring tools that try to mimic what a web page should look like by using excessive FONT tags and nbsp characters. These tools end up creating web pages that are impossible to keep maintained. There is a program you can use, if you've created one of these disaster pages, called the HTML Tidy Program which you can actually download here . This will clean up your code as well as possible.
3. You want your web pages readable to people who have disabilities - People who surf the Internet depend on speech synthesizers or Braille readers to interpret the text on the page. If your HTML markup is sloppy or isn't contained in CSS the software these people use to read pages have a difficult time in interpreting these pages. You should also include descriptions for each image on your page. Also, don't use server side image maps. If you are using tables you should include a summary of the table's structure and also associate table data with the correct headers. This gives non visual browsers a chance to follow the page as they go from one cell to another. And finally, for forms, make sure you include labels for form fields.
By following just these three guidelines you give your visitors, especially disabled visitors the best chance of having an enjoyable visit to your site while at the same time making it so that if you have to make changes to your site, those changes can be made easily and quickly.2 -
You know how the machine learning systems are in the news (and Ted talks, tech blogs, etc.) lately over how they're becoming blackbox logic machines, creating feedback loops that amply things like racism on YouTube, for example. Well, what might the ML/AI systems be doing with our code repositories? Maybe not so much yet, I don't know. But let's imagine. Do you think it's probably less worrisome? At first I didn't see as much harm potential, there's not really racist code, terrorist code, or code that makes people violence prone (okay, not entirely true...), but if you imagine the possibility that someone might use code repositories to create applications that modify code, or is capable of making new programs, or just finding and squishing bugs in code algorithmically, well then you have a system that could arguably start to get a little out of control! What if in squashing code bugs it decides the most prevalent bugs are from code that takes user input (just one of potentially infinite examples). Remember though, it's a blackbox of sorts and this is just one of possibly millions of code patterns it's finding troublesome, and most importantly it's happening slowly (at first). Just like how these ML forces are changing Google and YouTube algorithms so slowly that many don't notice the changes; this would presumably be similar and so it may not be as obvious as one would think. So anyways, 'it' starts refactoring code that takes user input into something 'safer'. Great! But what does this mean? Not for this specific example really, but this concept of blackbox ML/AI solutions to problems we didn't realize we had, what does a future with this stuff look like (Matrix jokes aside)? Well, I could go on all day with imaginative ideas... But talking to myself isn't so productive, let's start a fun community discussion here! Join in if you find this topic as interesting as I do! :)
Note: if you decide to post something like "SNN have made this problem...", or other technical jargan please explain it as clearly as possible. As the great Richard Feynman once said, the best way to show you understand a thing is to be able to explain it clearly to others who don't understand it... Or something like that ;)3