!rant

This was over a year ago now, but my first PR at my current job was +6,249/-1,545,334 loc. Here is how that happened... When I joined the company and saw the code I was supposed to work on I kind of freaked out. The project was set up in the most ass-backward way with some sort of bootstrap boilerplate sample app thing with its own build process inside a subfolder of the main angular project. The angular app used all the CSS, fonts, icons, etc. from the boilerplate app and referenced the assets directly. If you needed to make changes to the CSS, fonts, icons, etc you would need to cd into the boilerplate app directory, make the changes, run a Gulp build that compiled things there, then cd back to the main directory and run Grunt build (thats right, both grunt and gulp) that then built the angular app and referenced the compiled assets inside the boilerplate directory. One simple CSS change would take 2 minutes to test at minimum.

I told them I needed at least a week to overhaul the app before I felt like I could do any real work. Here were the horrors I found along the way.

- All compiled (unminified) assets (both CSS and JS) were committed to git, including vendor code such as jQuery and Bootstrap.
- All bower components were committed to git (ALL their source code, documentation, etc, not just the one dist/minified JS file we referenced).
- The Grunt build was set up by someone who had no idea what they were doing. Every SINGLE file or dependency that needed to be copied to the build folder was listed one by one in a HUGE config.json file instead of using pattern matching like `assets/images/*`.
- All the example code from the boilerplate and multiple jQuery spaghetti sample apps from the boilerplate were committed to git, as well as ALL the documentation too. There was literally a `git clone` of the boilerplate repo inside a folder in the app.
- There were two separate copies of Bootstrap 3 being compiled from source. One inside the boilerplate folder and one at the angular app level. They were both included on the page, so literally every single CSS rule was overridden by the second copy of bootstrap. Oh, and because bootstrap source was included and commited and built from source, the actual bootstrap source files had been edited by developers to change styles (instead of overriding them) so there was no replacing it with an OOTB minified version.
- It is an angular app but there were multiple jQuery libraries included and relied upon and used for actual in-app functionality behavior. And, beyond that, even though angular includes many native ways to do XHR requests (using $resource or $http), there were numerous places in the app where there were `XMLHttpRequest`s intermixed with angular code.
- There was no live reloading for local development, meaning if I wanted to make one CSS change I had to stop my server, run a build, start again (about 2 minutes total). They seemed to think this was fine.
- All this monstrosity was handled by a single massive Gruntfile that was over 2000loc. When all my hacking and slashing was done, I reduced this to ~140loc.
- There were developer's (I use that term loosely) *PERSONAL AWS ACCESS KEYS* hardcoded into the source code (remember, this is a web end app, so this was in every user's browser) in order to do file uploads. Of course when I checked in AWS, those keys had full admin access to absolutely everything in AWS.
- The entire unminified AWS Javascript SDK was included on the page and not used or referenced (~1.5mb)
- There was no error handling or reporting. An API error would just result in nothing happening on the front end, so the user would usually just click and click again, re-triggering the same error. There was also no error reporting software installed (NewRelic, Rollbar, etc) so we had no idea when our users encountered errors on the front end. The previous developers would literally guide users who were experiencing issues through opening their console in dev tools and have them screenshot the error and send it to them.
- I could go on and on...

This is why you hire a real front-end engineer to build your web app instead of the cheapest contractors you can find from Ukraine.

I'm editing the sidebar on one of our websites, and shuffling some entries. It involves moving some entries in/out of a dropdown and contextual sidebars, in/out of submenus, etc. It sounds a little tedious but overall pretty trivial, right?

This is day three.
I learned React+Redux from scratch (and rebuilt the latter for fun) in twice that long.

In my defense, I've been working on other tasks (see: Alerts), but mostly because I'd rather gouge my freaking eyes out than continue on this one.

Everything that could be wrong about this is. Everything that could be over-engineered is. Everything that could be written worse... can't, actually; it's awful.

Major grievances:
1) The sidebars (yes, there are several) are spread across a ridiculous number of folders. I stopped counting at 20.
2) Instead of icon fonts, this uses multiple images for entry states.
3) The image filenames don't match the menu entry names. at all. ("sb_gifts.png" -> orders); active filenames are e.g. "sb_giftsactive.png"
4) The actions don't match the menu entry names.
5) Menu state is handled within the root application controller, and doesn't use bools, but strings. (and these state flags never seem to get reset anywhere...)
6) These strings are used to construct the image filenames within the sidebar views/partials.
7) Sometimes access restrictions (employee, manager, etc.) are around the individual menu entries, sometimes they're around a partial include, meaning it's extremely difficult to determine which menu entries/sections/subsections are permission-locked without digging through everything.
8) Within different conditionals there are duplicate blocks markup, with duplicate includes, that end up render different partials/markup due to different state.
9) There are parent tags outside of includes, such as `<ul>#{render 'horrific-eye-stabbing'}</ul>`
10) The markup differs per location: sometimes it's a huge blob of non-semantic filthiness, sometimes it's a simple div+span. Example filth: section->p->a->(img,span) ... per menu entry.
11) In some places, the markup is broken, e.g. `<li><u>...</li></u>`
12) In other places, markup is used for layout adjustments, such as an single &nbsp; nested within several divs adorned with lots of styles/classes.
13) Per-device layouts are handled, not within separate views, but by conditionally enabling/disabling swaths of markup, e.g. (if is_cordova_session?).
14) `is_cordova_session` in particular is stored within a cookie that does not expire, and within your user session. disabling it is annoying and very non-obvious. It can get set whether or not you're using cordova.
15) There are virtually no stylesheets; almost everything is inline (but of course not actually everything), which makes for fun layout debugging.
16) Some of the markup (with inline styling, no less) is generated within a goddamn controller.
17) The markup does use css classes, but it's predominately not for actual styling: they're used to pick out elements within unit tests. An example class name: "hide-for-medium-down"; and no, I can't figure out what it means, even when looking at the tests that use it. There are no styles attached to that particular class.
18) The tests have not been updated for three years, and that last update was an rspec version bump.
19) Mixed tabs and spaces, with mixed indentation level (given spaces, it's sometimes 2, 4, 4, 5, or 6, and sometimes one of those levels consistently, plus an extra space thereafter.)
20) Intentional assignment within conditionals (`if var=possibly_nil_return_value()`)
21) hardcoded (and occasionally incorrect) values/urls.

... and last but not least:
22) Adding a new "menu sections unit" (I still haven't determined what the crap that means) requires changing two constants and writing a goddamn database migration.

I'm not even including minor annoyances like non-enclosed ternaries, poor naming conventions, commented out code, highly inefficient code, a 512-character regex (at least it's even, right?), etc.

just.

what the _fuck_

Who knew a sidebar could be so utterly convoluted?

Made the notif. list more readable B-)

Boss: We need to make a site but the content will have bolded words where the user can hover over to see more for each term.

Me: Ok sounds simple.

B: It's for a client and we aren't gonna touch it in the future so make it simple.

M：okay... so no JavaScript?

B: That means we are only going to send them HTML and nothing else. Here's a list of the images they have.

Me:......

Now I have to make about 80 pages of pure html with inline styles on each page.

I'm a stupid twat. Spent at least three hours today, all wasted. I had to update a user manual and change all the branding for a system I've licencesd and going to resell to my dumb clients. There was no original to work from only a pdf. Managed to convert it to word but all the formatting was fucked. So set up some heading and paragraph styles, proper header and footer and auto generate TOC's. I did all this without actually reading it, thought I'd get the formatting and branding out of the way first. So after all that I started the job of editing it and updating it. Quickly realised that PDF I converted was for a different but similar system. Tommorow is Groundhog Day.

Forms with autofocus. What are your opinions on that?

My boss keeps asking us to always give autofocus to the first input of a form, without any UX study to support it, just his opinion ("I think it makes sense"). I fucking hate it. He says it's nice for keyboard users, but I'm a keyboard user myself and I say that's what the tab key is for. To fucking focus stuff.

It really annoys me to no end when things like this are requested, but it's ok to have buttons, checkboxes, etc without fucking :focus and :active styles. Just :hover is not enough ffs.

And "links" that work with "onclick". Damn how I want to kill anyone that does that.

I think I might change my middle name to "I told you so"

Couple of weeks ago I proposed integrating a daily process job into an existing WPF application (details of what+why would be too long to explain) and the manager suggested I make the changes

Me: "I can do it, but Jay has the most experience with that application. I don't have his WPF skills"
Mgr: "How hard can WPF be? If it uses the MVVM pattern, it should be a snap."
Me: "Its nearly an 8 year old WPF project with several chefs in that kitchen. I pretty sure I could figure it out, but that is a difference between 2 weeks and 2 days. Integration is pretty straight forward, Jay could probably do it in a day."
DevA: "WPF is easy. MVVM makes it even easier. I worked on the shipping app."
Me: "That's was a brand new, single page app, but yea, it should be easy."
DevB: "WPF has been around a long time and the tools have really matured. I don't understand what is so difficult."
Me: "I didn't say anything would be difficult, I know with that application, there is going to be complexity we need to figure out."
DevB: "It uses the MVVM, so all we need is the user control, a view model, controller, and its done."
DevA: "Sounds easy to me."
Mgr: "If you need more time to work on the vendor project, I'll have DevB work on the integration."

<yesterday>
Me: "How is the integration going?"
DevB: "This app is a mess. I have no idea how they got the control collections to work. If I hard-code everything, I can get it to work. This dynamic stuff is so confusing. Then there is the styling. Its uses dark mode, but no matter what I do, my controls show up in light mode."
Me: "The app uses Prism, so the control configuration is in, or around, the startup code."
DevB: "That makes sense. Will it fix the styling too?"
Me: "I have no idea. When I looked at it, some controls loaded the styles from the main resource, other's have it hard-coded. Different chefs in the kitchen, I guess. How far have you got?"
DevB: "I've created invoice button. That is as far as I got"
Me: "I'm finished with the vendor project and I'll be wrapping up the documentation today. I can try to help next week."
DevB: "Thanks. I think we might have to get Jay to help if we can't figure this out."
Me: "Good idea"

Two weeks and only a button. A button? I miss Delphi.

Fuck Homestead.

For the fortune of you not to know, Homestead is a sad attempt at a Wix-like build your own website platform.

However, Homestead is the most unusable piece of shit platform that humans have ever had the misery of interacting with

Lets start off with the login page. The login page is small, unresponsive and half the time just deletes your input whenever you press submit.

It's important to note that unless you're running MacOS or Windows, Homestead will send to an error page on which there's a link to contact support, but pressing that link requires MacOS or Windows.

Fine, I'll fiddle around with my user-agent, and we'll be in soon enough. But now we come to the joy that is the website editor itself.

The website editor is clunky, hard to use, and has enough menus and submenus and sidebars to make the Jira UI shake with fear. Each interface option label is either ridiculously ambiguous or just straight up wrong. The built-in HTML editor doesn't support HTML5, in the name of "browser compatibility".

CSS? Pah! Who needs it! Our psuedo-90s skeuomorphic ugly-as-shit prebuilt styles will work just fine. Responsive design? Bullshit! Nobody uses a smartphone to browse the web, so why do we need to handle it?

Uploading a file? Good fucking luck buddy. There's a complicated dance among the minefield of pop-ups that ask you to confirm some shit or modify some shit and you gotta click the right option each time or else the file won't upload.

Wanna use https like 86% of the entire web and all modern websites? That's a premium feature. Fork over an extra $10 a month

Ok ok, I made it through all that. Dig through the thousands of menus to find the 'publish changes' button, and sigh with relief.

Open up a private browser tab to check my work, and nope. The site looks like shit, even by Homestead's standards. That's because Homestead claims to be a WYSIWYG editor, but it's a damn lie. The site looks like shit, so it's time do dive back into the hellhole that is this damn site editor.

And rinse and repeat. Deal with the shitty editor, publish, and pray it doesn't look like garbage. Be too scared to test on other devices because this flaming pile of dog shit pretending to be a website is bad enough on my device.

Two more months, then I'm done with this client. Someone get me a drink

I continue to internally read and study about Smalltalk in an effort to see where we might have FUCKED UP and went backwards in terms of software engineering since I do not believe that complex source code based languages are the solution.

So I have Pharo. Nothin to complex really, everything is an object, yet, you do have room for building DSL's inside of it over a simple object model with no issue, the system browser can be opened across multiple screens (morph windows inside of a smalltalk system) for which you can edit you code in composable blocks with no issues. Blocks being a particular part of the language (think Ruby in more modern features) give ample room for functional programming. Thus far we have FP and OO (the original mind you) styles out in the open for development.

Your main code can be executed and instantly ALTER the live environment of a program as it is running, if what you are trying to do is stupid it won't affect the live instance, live programming is ahead of its time, and impressive, considering how old Smalltalk is. GUI applications can be given headless (this is also old in terms of how this shit was first distributed) So I can go ahead and package the virtual machine with the entire application into a folder, and distribute it agains't an organization "but why!!!! that package is 80+ mbs!") yeah cuz it carries the entire virtual machine, but go ahead and give it to the Mac user, or the Linux user, it will run, natively once it is clicked.

Server side applications run in similar fashion to php, in terms of lifecycles of request and how session storage is handled, this to me is interesting, no additional runtimes, drop it on a server, configure it properly and off you go, but this is common on other languages so really not that much of a point.

BUT if over a network a user is using your application and you change it and send that change over the network then the the change is damn near instant and fault tolerant due to the nature of the language.

Honestly, I don't know what went wrong or why we are not bringing this shit to the masses, the language was built for fucking kids, it was the first "y'all too stupid to get it, so here is simple" engine and we still said "nah fuck it, unlimited file system based programs, horrible build engines and {}; all over the place"

I am now writing a large budget managing application in Pharo Smalltalk which I want to go ahead and put to test soon at my institution. I do not have any issues thus far, other than my documentation help is literally "read the source code of the package system" which is easy as shit since it is already included inside. My scripts are small, my class hierarchies cover on themselves AND testing is part of the system. I honestly see no faults other than "well....fuck you I like opening vim and editing 300000000 files"

And honestly that is fine, my questions are: why is a paradigm that fits procedural, functional and OBVIOUSLY OO while including an all encompassing IDE NOT more famous, SELECTION is fine and other languages are a better fit, but why is such environment not more famous?

markdown is not good enough! the tools aren't there for non-devs and there's no concordance on moving forward *compatibly* for anything other than headers and __possibly__ lists.

md has been around for years and still no consensus on comments, meta data, css, data imports, etc.

i could never in good faith recommend to a non-dev to use markdown, even though every academic and professional writer from legal to journalism should exclusively be using markdown to write and store their documents. the data portability and ease of search, retrieval, collection, distribution, etc of markdown compared to pdf or docx is enormous. markdown is the hex format of text, the perfect layer of data and visual so that the user and the computer can both operate on text as blocks of data rather than weirdly styled paragraphs that need to be reformatted BY HAND for citation-style or journal format, or paper size. FOR EACH SUBMISSION. Academics literally rewrite their 100-page papers to accommodate up to 10 different submission requirements.

They could be clicking MLA vs Chicago and/or using a journal's stylesheet to recompile for its styles.

Today there is some support from zotero et al to take away some of the pain, but it makes ZERO SENSE for writers to have to keep and store and keep up to date, multiple versions of the same document. Git pull does not exist for them. But the worst part is that git isnt the solution to their problem. They need a compiler more than they need version control. But they also desperately need vcs. They ALL literally have a million files named "dumdum.dumFINAL-3084_lastversion \2020, this one.dum".

They dont have git or anything like it, because they need a line-by-line solution like markdown for git to become effective.

All of writing is basically mired in the fact that people cant even roll up their paragraphs and see what the fuck it is theyre saying. Most writing reads like a long scroll through some nonsense that goes nowhere. Like this rant. but the point is that markdown and line-by line editing actually produces more logically sound writing. You start to think in terms of defining ideas in blocks, ... like code.

Fucking hell, our .net site uses a modal pop-up after the user submits data so they can explain what the did and why. Bootstrap styles it with an x in the top right, but the x doesn't do anything. I can't find where bootstrap adds it, I can't find any way to access it, it just annoys users because if they don't need to explain, they click it, and it doesn't work. Only the cancel button closes it. Where the fuck does this thing come from?

TL;DR - Coding standards are a shit practice IMO.

What we don't talk about enough among software engineers, is the artistic aspect of the craft of writing code.

For example, consider your client saying this to you.

"Build me a web app where a user will login. They will have a wallet to purchase subscriptions of 3 products of different prices."

Give these two statements to say, 10 devs and see how each of them will come up with their own vision of the problem and how they would implement it in their own ways.

So now you are working on a big team with say 30 people and you have a big project to work on. Different members of the team bring different styles of code to you to review and if, the Team Leader is as incompetent as mine is, they would find it troubling to understand the pull requests.

So what do you do in these scenarios? Implement Coding standards !!! They take away the artistic vision of the devs and tries to force them to follow rules like sheep.

Also the company doesn't give two shits about the code standards cuz, as long as they have working code that makes them money, they wouldn't care how the code is written.

Thoughts ?

I have review-style pages where I use h1, h2, and h3 to indicate the magnitude of a point I'm making. I liked it. I recently changed my template so it's all wrapped in an <article>, and just today I noticed that my h1s appear as h2s. Firefox wouldn't tell me what was going on, but Chromium let me see the relevant styles from the user agent style sheet, and WTF, h1s inside <article> or a few other semantic tags get styled to look exactly like h2s. WTF?!? I want my h1s back! But I don't want to pollute my stylesheet, and there isn't a good way to either, since I shouldn't be hardcoding the size of an h1 without hardcoding all the header sizes.