HOME | DD
dt β We Give a F*** How the Site Loads
Published: 2013-08-12 15:24:00 +0000 UTC; Views: 117340; Favourites: 41; Downloads: 0
Redirect to original
Description
body div#devskin1262065 .gr-body { background:#FFFFFF; font:10pt/1.4em Verdana; border-bottom:1px solid #A6B2A6; } body div#devskin1262065 i.gb { display:none; } body div#devskin1262065 a { text-decoration:none; color:#2f779e; } body div#devskin1262065 a:hover { text-decoration:underline; } body div#devskin1262065 img { max-width:100%; } body div#devskin1262065 strong { font:bold 15px/normal Verdana, Geneva, sans-serif; color:#404040; margin:0 0 -10px; display:block; } body div#devskin1262065 p { max-width:800px; width:auto!important; width:800px; margin:0; } body div#devskin1262065 code { font:normal 11px/20px Monaco, 'Courier New', Courier, monospace; color:#1b3c59; background:#f2f6ff; border:1px solid #ccddff; display:block; padding:6px 0 20px 10px; border-radius:3px; -moz-border-radius:3px; -webkit-border-radius:3px; margin:5px 0px 5px 0px; } body div#devskin1262065 div.positions { text-align:center; background:#0F3B6A; border-radius:4px; -moz-border-radius:4px; -webkit-border-radius:4px; padding:0 10px 1.3em 10px; margin:0 20px; } body div#devskin1262065 div.positions a { text-decoration:none; color:white; } body div#devskin1262065 div.positions a:hover { text-decoration:underline; }
Developers can be angry people sometimes. This is actually quite the understatement and dt is no exception to that assessment. With web development in particular, there are several moments during the day where we are astounded, perplexed, and irritated by why something works the way it does--often over things beyond our control like lack of uniform web standards. Abe Stanway, the creator of Commit Logs from Last Night, actually gives a pretty compelling, and serious, Ignite talk on the functionality of profanity for developers here:
(It has several cool histograms and visualizations of how developers use profanity and which languages it's most prevalent in--surprise ending: Javascript generates the most profanity)
Last week, we received a very interesting, if not amusing, bug report:
"I just wanted to let you know that the reason why deviantART's CSS isn't loading properly for some people is because one of your CSS files has f*** in a stylesheet comment."
That's right. The almighty F-word was breaking how some stylesheets were loading for deviants who were accessing the site from computers with overly sensitive system-wide profanity filters installed. These users' browsers likely stopped parsing the stylesheet entirely upon reaching the word in the stylesheet, leading to a fairly ugly and/or broken page.
The irony here is that we didn't have to do anything to fix this bug (well, we did have to rename an image file that had a vulgar name!).
Why didn't we have to do anything?
Last week, we made a pretty big switch in how we build stylesheets on deviantART. We started using LESS with the CSS rollup files that we build (deviantART has hundreds of stylesheets--we combine these into single rollup files to reduce the number of requests your browser has to make). Β One of the outcomes of this switch was that we no longer serve stylesheets with developer comments left in.
Oops. We're sorry, everyone. We can't promise we'll never swear again. But we can promise if you're browsing deviantART at the public library, our swearing won't stop you from using the site.
Like the idea of working on stuff like this? Check out the open developer positions at deviantART.
Related content
Comments: 96
Lovely. Now let's see if we can get the "your browser is not a *-nightly" warning to go away.
Love, an Opera user on Ubuntu (yeah, there's newer Blink-based Operas out there but I still haven't found what doesn't work on DA on Opera. So to access the top menu without constantly closing the thing, I had to write my own rule in the browser's user stylesheet).
Hah, I'm no fan of LESS but it certainly is an advantage that I can swear more in development knowing someone won't see those comments when accessing the .css file via the website.
π: 0 β©: 0
Confession: it was me who complained, because I couldn't access deviantART from school. Thanks for the epic follow-up! :C
π: 0 β©: 1
/me rolls on the floor laughing crazily
I used to do web development... I feel you guys. Totally. XDDD
π: 0 β©: 1
p.s.: And I used to have some of the most insane comments in my code occasionally. Or writing comments in haiku form... *rolls eyes*
π: 0 β©: 0
I only just now realized that the CSS is also now minifyed ... I love how it has saved almost 100KB in just 4 CSS files on the main page, It's truly nice. Should help out with the mobile side of things too.
π: 0 β©: 0
Why wouldn't you minify your css files anyway?
That's rather ridiculous coming from a huge website like da
π: 0 β©: 1
I don't know why, but it was just never done. (Speaking as a ex-web developer at dA) I don't know why we never put the effort into changing that but I do know it wasn't just a simple "ok lets turn this on" sort of change. I do know there was talk multiple times to change it but it just never happened.
π: 0 β©: 1
How come it's not just a "turn it on" sort of change? all you have to do is minify your assets before you commit the changes. Hell there are so many tools out there to do it for you (like for example save for autominification).
π: 0 β©: 2
It wasn't just 'turn it on' because no CSS minifiers handle the many IE6 hacks we had throughout our CSS.
i.e. we tried 'just turning it on' and tons of stuff either failed to compile or broke and until recently we didn't make the effort to go and strip out all those old hacks (mostly because we don't support IE6 anymore and don't need many of them).
π: 0 β©: 0
That's the low-tech manual way of doing it and it's not suitable for large codebases with a lot of CSS/JS such as dA. They have have two systems called DWait & Jenny CraigΒ (Read more on the systems here ) which takes a list of CSS/JSΒ and combines them into a single file instead of serving manny. It's easier to work on a bunch of separate files (which allows more flexibility) then to work on a single massive file. A CSS file (in this instance) is committed unminifyed and after the system combines the files, it minifys it and stores it separately. This allows the developers to develop on a unminifyed version of the CSS/JS to debug problems but still serve the minifyed version out to users. This is the system that dA pretty much has in place, the missing component until recently was the CSS being minifyed also.
π: 0 β©: 1
That's what I'm saying.
Once the system prepares the final combined CSS file, all you have to do is minify it...
π: 0 β©: 0
This is pretty hilarious. Especially that profanity filters check the areas like CSS files, where it's fairly hard (I think impossible?) for normal users to even find, let alone read through. But, if I may, why on earth is that quote image a picture of a roulette board??
π: 0 β©: 2
CSS can be used to add visible content on the page though, so that's probably why.
π: 0 β©: 0
It's not hard, and it is certainly not impossible.
π: 0 β©: 1
True, but highly unlikely, wouldn't you say?
π: 0 β©: 1
yeah, the average use doesn't go looking through someone else's CSS. I do from time to time, but the majority of web users probably don't.
π: 0 β©: 0
I completely sympathize with the emotion, if not the occasional word when getting all the little details and programs to work together. But I still laughed my head off that a developer comment would generate a bug. I didn't think that the system that parsed the CSS was supposed to read or parse comments...
π: 0 β©: 0
Ah, leave it to an art site... Truly putting the style in stylesh***s!
π: 0 β©: 0
Is it odd that I found that somewhat amusing?
π: 0 β©: 1
No, I found it rather amusing too. Β Although the site filters really shouldn't worry about cuss words in a css file most people won't even see!
π: 0 β©: 2
There is a "content" attribute for CSS which one can use to display text inside a container. That's why CSS is also filtered
π: 0 β©: 2
To be fair, you can very easily get around something like that with before: 'fu'; and after: 'ck';
π: 0 β©: 0
This is true⦠I guess it can't really tell the difference! XD
π: 0 β©: 1
They could program it so it knows what type of file it's looking at!
π: 0 β©: 0
You're free to use the F-bomb as you please 
π: 0 β©: 1
Oh dear. Thanks for the tip if I ever expand my CSS skills.
π: 0 β©: 0
Interesting. Why did you decide to use LESS and not SASS? I'm not saying one is better than the other, but I wonder how you decided this? Maybe I got the wrong impression but I think more people use SASS. I think SASS was better integrated in Rails last time I checked. Might be different now.
π: 0 β©: 1
Less worked for us and we had more devs who were familiar with it. So there wasn't a need to shop around further.
Rails integration doesn't matter for us, we're a PHP shop.
π: 0 β©: 2
Huh. Well, I can add this to the list of well-known sites that run on PHP. I'm actually quite surprised; I figured all the sites that have their own dedicated coding staffs had switched to something else by now.
π: 0 β©: 1
As far as I know it's generally considered really bad practice to try and rewrite an entire code base, especially when it's as old as dA's, let alone into another language.
π: 0 β©: 0
Well, sort of you do.
I tried to raise a bug report a while ago, saying that on a slow link, with large latency, dA breaks - renders as horrible text, or, most often, with missing thumbnails. Maybe due to the 233kB of css that it pulls down. Other sites load slowly, but load. dA breaks.
The response was rather underwhelming, I'm afraid.
I know I'm at the bottom of Africa, and not a huge target market, but slow and broken are different. Broken implies brittle.
The pathping from SA to dA makes for interesting reading - just short of 200ms latency on the "other" (your) side of the pond.
Just an outsiders observation.
Grant H
π: 0 β©: 1
I get the same problems in UK. DA is almost unusable most of the time.
π: 0 β©: 1
The Atlantic is wide... the little fishies have to swim far with our data ...
π: 0 β©: 1
I think a lot of the problems are at the DA end - it was so bad a few months ago that I made a picture of a tracert and sent it to their support team formatela.deviantart.com/art/Pβ¦
2 weeks after I sent it to them I got an email asking if I was still having the problem. I told them I was and I've heard nothing back from them since then.
π: 0 β©: 1
The request timed out is a normal occurrence, if you read this article it state "the *sβ are due to a firewall blocking traceroute packets. This is perfectly normal.". It does not point to a flaw on dA's end, rather a router that is blocking your traceroute packets causing the rest of the traceroute to be lost. Any slowdown could be caused by the CDN (content delivery network) or other factors, but a traceroute isn't a set in stone reason for slowdowns.
π: 0 β©: 1
No, that's not correct. The tracert gets through to DA most of the time, but not always, so it doesn't point to a router blocking packets, unless it's something they arbitrarily turn on and off whenever they feel like it - and the tracert got right the way through until it got as far as DA's network, then it timed out. An hour later DA was available and the tracert was also getting right the way through.
π: 0 β©: 1
It's because you don't always go down the same network path everytime ... network routing is a ever-changing so you may never go down the extact same path 100% of the time. From one traceroute to the next, you may get a router that's not blocking traceroute packets.
π: 0 β©: 0
the logo effect using dtbg.png is pretty cool, unrelated but I thought you should know
π: 0 β©: 0
| Next =>