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
-
I worked with a good dev at one of my previous jobs, but one of his faults was that he was a bit scattered and would sometimes forget things.
The story goes that one day we had this massive bug on our web app and we had a large portion of our dev team trying to figure it out. We thought we narrowed down the issue to a very specific part of the code, but something weird happened. No matter how often we looked at the piece of code where we all knew the problem had to be, no one could see any problem with it. And there want anything close to explaining how we could be seeing the issue we were in production.
We spent hours going through this. It was driving everyone crazy. All of a sudden, my co-worker (one referenced above) gasps “oh shit.” And we’re all like, what’s up? He proceeds to tell us that he thinks he might have been testing a line of code on one of our prod servers and left it in there by accident and never committed it into the actual codebase. Just to explain this - we had a great deploy process at this company but every so often a dev would need to test something quickly on a prod machine so we’d allow it as long as they did it and removed it quickly. It was meant for being for a select few tasks that required a prod server and was just going to be a single line to test something. Bad practice, but was fine because everyone had been extremely careful with it.
Until this guy came along. After he said he thought he might have left a line change in the code on a prod server, we had to manually go in to 12 web servers and check. Eventually, we found the one that had the change and finally, the issue at hand made sense. We never thought for a second that the committed code in the git repo that we were looking at would be inaccurate.
Needless to say, he was never allowed to touch code on a prod server ever again.8 -
Production is down
Me to Customer :What did you do?
Customer: Nothing
Me blurt out: The fuck you didn't!
Customer: ...
Me: ...(fuckfuckfuck)
Customer:... Well, I did run these scripts..
Me: (oh thank Christ)
Me: ok, I'll get right on it (Click)
Me to TeamLead: client called. Their prod is down!
TeamMate: did he say he didn't do anything?
Me:Yes
TeamMate: ..... Every fucking time...14 -
My coworker complained about an way to big Angular build (20 MB in prod!).
We looked over his code.
... Well deleting that 200 unused base64 encoded images shrinked it down to 500kB
DELETE the Code you replace14 -
Colleagues sharing passwords.That was a big fat NO when I was a sysadmin - and for a good reason. But now, since I'm closer to development, it feels like no one really cares about the passwords. If I tell my colleague I'll take 10 minutes more because I can't log in, he OFFERS me his credentials. And sends them over saying "in case you need it". [the next day the same colleague was complaining his account is locked out. Oh, wonders! How on Earth...!]
But seriously, password sharing is a serious problem. I would fire the person on spot if I caught him sharing his credentials! This is the 8th deadly sin! IDC if they are for non-prod. Most people reuse their passwords in multiple systems, and even non-prod envs can bring the prod down! Or worse - install a trojan.15 -
This is going to be a long rant, coz this is the only way to vent out my frustration against our tech head.
Yesterday, while our fucking twat tech head was playing around in company aws account, he terminated the production server. By mistake, apparently. Coz he doesn't know shit about server management. But that egoist ass won't admit and fucked the production server.
And then ran away. We developers sprang into action. Updated dns to point to staging server, setup virtual hosts, env files, point to prod database, force flush dns cache. All systems were up and running in 30 mins. And since it was staging server, it had lot of untested features and codes, and we spent rest of the day fixing the bugs.
And that tech head, who ran away hiding his tail between his legs, after he fucked the server, came back after systems were up. And started cracking jokes, that "so many features got released in 1 day" . "We cut server cost by shutting down 1 server."
We were struggling and working in full throttle to make the services running again. And that fuckity fucker was cracking jokes.
And I don't even know what excuse he gave to ceo for the downtime. I am pretty sure he would have made up some crappy excuse to hide his fucking mistake. That ass never admits his mistake. I am thinking to go to ceo today and tell the real story and get that faggot head fired or at least a strict warning.4 -
The riskiest dev choice...
How about "The riskiest thing you've done as a dev"? I have a great entry for that. and I suppose it was my choice to build the feature afterall.
I was working on an instance of a small MMO at a game company I worked for. The MMO boasted multiple servers, each of them a vastly different take on the base game. We could use, extend, or outright replace anything we wanted to, leading to everything from Zelda to pokemon to an RP haven to a top-down futuristic counterstrike. The server in this particular instance was a fantasy RPG, and I was building it a new leveling and experience system with most of the trimmings. (Talents, feats/perks, etc. were in a future update.)
A bit of background, first: the game's dev setup did not have the now-standard dev/staging/prod servers; everything ran on prod, devs worked on prod, players connected and played on prod, etc. Worse yet, there was no backup system implemented -- or not really. The CTO was really the only person with sufficient access. The techy CEO did as well, but he rarely dealt with anything technical except server hardware, occasionally. And usually just to troll/punish us devs (as in "Oops ! I pulled the cat5 ! ;)"). Neither of them were the most reliable of people, either. The CTO would occasionally remote in and make backups of each server -- we assumed whenever he happened to think of it -- and would also occasionally do it when asked, but it could take him a week, sometimes even up to a month to get around to it. So the backups were only really useful for retreiving lost code and assets, not so much for player data.
The lack of reliable backups and the lack of proper testing grounds (among the plethora of other issues at the company) made for an absolutely terrible dev setup, but that's just how it was, and that's what we dealt with. We were game devs, afterall. Terrible or not, we got to make games! What more could you ask for!? It was amazing and terrible and wonderful and the worst thing ever, all at the same time. (and no, I'm not sharing the company name, but it isn't EA or Nexon, surprisingly 😅)
Anyway, back to the story! My new leveling system also needed to migrate players' existing data, so... you can see where this is going.
I did as much testing and inspection of my code as I could, copied it from a personal dev script to the server's xp system, ... and debated if I really wanted to click [Apply]. Every time I considered it, I went back to check another part or do yet more testing. I ended up taking like 40 minutes to finally click it.
And when I did... that was the scariest button press of my life. And the scariest three seconds' wait afterwards. That one click could have ruined every single player's account, permanently lost us players ...
After applying it, I immediately checked my character to see if she was broken, checked the account data for corruption or botched flags, checked for broken interactions with the other systems....
Everything ended up working out perfectly, and the players loved all of the new features. They had no idea what went into building them, and certainly had no idea of what went into applying them, or what could have gone wrong -- which is probably a good thing.
Looking back, that entire environment was so fragile, it's a wonder things didn't go horribly wrong all the time. Really, they almost never did. Apocalypses did happen, but were exceedingly rare, and were ususally fixed quickly. I guess we were all super careful simply because everything was so fragile? or the decent devs were, at least. We never trusted the lessers with access 😅 at least on the main servers where it mattered. Some of the smaller servers... well, we never really cared about those.
But I'm honestly more surprised to realize I've never had nightmares of that button click. It was certainly terrifying enough.
But yay! Complete system overhaul and migration of stored and realtime player data! on prod! With no issues! And lots of happy players! Woooooo!
Thinking back on it makes me happy 😊1 -
Got a call while on vacations, the main server is down.
*holy shit* I thought.
As I opened my MacBook, the phone kept ringing and slack was going crazy.
“What should I do? Where is the problem?”, the voices in my head said..
I opened the terminal and tried to get a ssh connection.
Sweat was dropping down from my forehead.
“Connected” the terminal said.
“Fuck yeah, the server is up, only the app is not responding”, I thought and opened the log files.
Suddenly, “STOP” I shout at the log files that were appended way too fast.
Then I saw it.
TimeOutExceptions..
I added an index to the modification date column,“ kill -9“ed the process, started again and went back to vacation mode 🙂
And of course I was the office hero for a while💪
For the smart asses, I’m aware that it’s a bad idea to -9 the app process in prod, but it was so overloaded that i was not able to kill it any other way. And we needed that server up again.4 -
# 3 weeks ago
customer informed us that the app will get quite some load since the beginning of July
# this monday
last spare hdd on database's SAN died.
I told everyone another hdd is to follow it very soon eithet whether nothing is done at all or if anyone attempts to touch the san array [cuz that's what redundant raids do...]. No fucks given by anyone, no attempts to have maintenance and planned outage within 24 hrs....
# this morning
another hdd has failed and now 1tb of data is lost. No way to restore backups cuz there is no database to restore them to....
# 20 minutes later I head out to get some popcorn. It's gonna be a fun week!
So... The planned heavy load [and revenue along with it] is not gonna happen... I guess they are gonna ha a week long outage.
That's what happens when you ignore warning shots fired at your face.2 -
Every year my team runs an award ceremony during which people win “awards” for mistakes throughout the year. This years was quite good.
The integration partner award- one of our sysAdmins was talking with a partner from another company over Skype and was having some issues with azure. He intended to send me a small rant but instead sent “fucking azure can go fuck itself, won’t let me update to managed disks from a vhd built on unmanaged” to our jv partner.
Sysadmin wannabe award (mine)- ran “Sudo chmod -R 700 /“ on one of our dev systems then had to spend the next day trying to fix it 😓
The ain’t no sanity clause award - someone ran a massive update query on a prod database without a where clause
The dba wannabe award - one of our support guys was clearing out a prod dB server to make some disk space and accidentally deleted one of the databases devices bringing it down.
The open source community award - one of the devs had been messing about with an apache proxy on a prod web server and it ended up as part of a botnet
There were others but I can’t remember them all4 -
A tip to tech folks from my personal xp.
If you fuck up and make an impacting mistake in your company, like taking PROD down, noone is going to fire you on spot. Assign some more mandatory trainings - maybe. So you'd be more careful next time.
See, it's not worth getting rid of someone who made a mistake. You should be seated down and insisted to fix it. If you don't - then they might consider firing it. If you do fix it [with help or alone] - you become a more valuable asset to the company as you prove you are responsible for your actions and you take it seriously. You show that you can clean up your own shit and you don't need a babysiter next to you.
If you simply make a mistake and they replace you with someone else, that someone else is likely to be unaware of your mistakes and is doomed to repeat them. It's just bad for business.
Ofc if you making mistakes becomes a tendency rather than an exception, it's also a red flag for the business.
Don't get too laxed! And always answer for your shit. Never hide a fuckup - always alarm about it asap so that corrective actions could be taken by respective organs of the company while you are fixing it.
Come up with an action plan, announce it. Estimate resources you need [like help from others] - announce that too. Update concerned parties every half an hour or so about the status. If you find you need anything else while fixing it or you come across some blockers/delays/change of impact - always announce asap. Do avoid false alarms and disinformation.
// inspired by someone's rant today7 -
TLDR - you shouldn't expect common sense from idiots who have access to databases.
I joined a startup recently. I know startups are not known for their stable architecture, but this was next level stuff.
There is one prod mongodb server.
The db has 300 collections.
200 of those 300 collections are backups/test collections.
25 collections are used to store LOGS!! They decided to store millions of logs in a nosql db because setting up a mysql server requires effort, why do that when you've already set up mongodb. Lol 😂
Each field is indexed separately in the log.
1 collection is of 2 tb and has more than 1 billion records.
Out of the 1 billion records, 1 million records are required, the rest are obsolete. Each field has an index. Apparently the asshole DBA never knew there's something called capped collection or partial indexes.
Trying to get approval to clean up the db since 3 months, but fucking bureaucracy. Extremely high server costs plus every week the db goes down since some idiot runs a query on this mammoth collection. There's one single set of credentials for everything. Everyone from applications to interns use the same creds.
And the asshole DBA left, making me in charge of handling this shit now. I am trying to fix this but am stuck to get approval from business management. Devs like these make me feel sad that they have zero respect for their work and inability to listen to people trying to improve the system.
Going to leave this place really soon. No point in working somewhere where you are expected to show up for 8 hours, irrespective of whether you even switch on your laptop.
Wish me luck folks.3 -
"Your XML is malformed by these strange tags CDATA. I've cleaned it up ;)"
Fuckity Fuck my boy, now the whole website is down. All hail the magic push to prod button.
(there were snippets of user provided HTML that was passed over XML by a microservice)6 -
Gather around folks, I'll paint you a nice picture based on a true story, back from my sysadmin days. Listen up.
It's about HP and their Solaris 5.4/6 support.
- Yet another Prod Solaris dinosaur crashed
- Connected to console, found a dead system disk; for some reason it was not booting on the remaining redundant disk...
- Logged an HP vendor case. Sev1. SLA for response is 30 minutes, SLA for a fix is <24 hours
- It took them 2 days to respond to our Prod server outage due to failed system disks (responses "we are looking into this" do not count)
- it took another day for them to find an engineer who could attend the server in the DC
- The field engineer came to the DC 4 hours before the agreed time, so he had to wait (DC was 4-5 hours of driving away from HP centre)
- Turns out, he came to the wrong datacentre and was not let in even when the time came
- We had to reschedule for two days later. Prod is still down
- The engg came to the DC on time. He confirmed he had the FRU on him. Looks promising
- He entered the Hall
- He replaced the disk on the Solaris server
- It was the wrong disk he replaced. So now the server is beyond rebuild. It has to be built anew... but only after he comes back and replaces the actually faulty disk.
- He replaced that disk on the wrong Solaris server2 -
Somewhere in a lonely break room
There's a guy starting to realize that eternal hell has been unleashed unto him.
It's two a.m.
It's two a.m.
The boss has gone
I'm sitting here waitin'
This desktop's slow
I am getting tired of fixin' all my coworkers' problems
Yeah there's a bug on the loose
Errors in the code
This is unreadable
Rubber ducky can't help
I cannot debug, my whole life spins into a frenzy
Help I'm slippin' into the programming zone
Git push to the prod
Set up a repo
My hard drive just crashed
All my code is gone
Where am I to go
Now that I've broke my distro
Soon you will come to know
When you need Stack Overflow
Soon you will come to know
When you need Stack Overflow
I'm falling down a spiral
Solution unkown
Disgusting legacy, ugly code
Can't get no connection
Can't get through to commit
Well the night weights heavy
On my confused mind
Where's the error on this line
When the CEO comes
He knows damn well
To keep his distance
And he says
Help I'm slippin' into the programming zone
Git push to the prod
Set up a repo
My hard drive just crashed
All my code is gone
Where am I to go
Now that I've broke my distro
Soon you will come to know
When you need Stack Overflow
Soon you will come to know
When you need Stack Overflow
When you need Stack Overflow
When you need Stack Overflow, a ha
When you need Stack Overflow
When you need Stack Overflow, a ha
When you need Stack Overflow
When you need Stack Overflow, a ha
When you need Stack Overflow
When you need Stack Overflow, a ha
When you need Stack Overflow4 -
I really, really, fucking god damn it REALLY need to move a legacy project from the grave yard server and get it in git, and then build a dev environment for it, so I can stop making incredibly volatile changes direct to PROD (backend, frontend and DB all at once and then test it while it’s live and being used, but fuck me if I can be bothered digging through a 10GB code base and attempting to make it work in a multi-environment setup when it’s going to be a long trip down the error logs until it works again 😱🔫2
-
Long time ago, back in a day of Microsoft Office 95 and 97, I was contracted to integrate a simple API for a payment service provider.
They've sent me the spec, I read it, it was simple enough: 1. payment OK, 2. payment FAILED. Few hours later the test environment was up and happy crediting and debiting fake accounts. Then came the push to prod.
I worked with two other guys, we shut down the servers, made a backup, connected new provider. All looked perfectly fine. First customers were paying, first shops were sending their products... Until two days later it turned out the money isn't coming through even though all we are getting from the API is "1" after "1"! I shut it off. We had 7 conference calls, 2 meetings, 3 days of trying and failing. Finally, by a mere luck, I found out what's what.
You see, Microsoft, when you invent your own file format, it's really nice to make it consistent between versions... So that the punctuation made in Microsoft Word 97 that was supposed to start from "0" didn't start from "1" when you open the file in Microsoft Word 95.
Also, if you're a moron who edits documentation in Microsoft Word, at least export it to a fucking PDF before sending out. Please. -
"Eh, just push it to prod and see if anything breaks"
The entire system went down for hours, estimated loss north of $1M.5 -
There is a company providing a very speciffic service. And it has a core application for that svc, supported by a core app team.
That company also has other services, which are derivations of the core one. So every svc depends on core.
Now that we're clear on that... I was working in a team of one of the subservices. We very strongly depended on core. In fact, our svc was useless if integration w/ core broke down.
The core team had an annoying habbit. They refused to version their webservices and they LOVED to push api updates w/o any warnings. Our prod, test, other envs used to fail bcz of core api changes quite often. Mgmt, IT head was aware of the problem and customers' complaints as well.
So as a result, once core api changes we're all in a panic mode: all prior priorities are lowered and revival of prod is to be our main focus. Core api is not docummented, the changes are not clear, so we have to reverse engineer the shit out of it. We manage to patch our prod up w/ hotfixes, but now we have tech debt. While working on the debt, core api changed again, in test env. Mgmt pushes debt back and reallocates us to hotfix test. Hotfix is 80% done when another core api breaks. Now mgmt asks us to drop wtv we're working on and fix that new break. By the time we're to deploy the hotfix, another api breaks in another env. The mgmt..... You get the picture :)
2 years go by, nothing has changed so far.6 -
Me: “Hey boss, you assigned these things to me that I’m not qualified for and have no experience in. We should really hire someone with the specialized skills in this”
Boss “I agree. It’s a role I desperately think we should have hired for a long time ago”
Me “Ok so about these tickets the-“
Boss “I need you to write up a justification for this role, what kind of work the person would be doing and what budget implications we will incur”
Me “You’re asking me to write a job description for a class of work I’ve already admitted I have no experience or qualifications doing MYSELF?”
Boss “Correct”
Me “and I’m still responsible in the meantime for getting these other tickets done still aren’t I?”
Boss “Yes”
Me “Very well. I’ll email you a recap of this discussion then so we can come back to it later when we start hiring for the role”
(and so my ass is sufficiently covered when I inevitably bring down prod and people start asking why I broke prod)5 -
I've been staffed on a old ongoing project, first day.
0. Compatibility has to be guaranteed down till IE9... ppf.
1. Front end made in XHTML+JS(jQuery)... bah, ok.
2. XHTML+JS is actually generated by PHP5.4, not a line is actually statically served... beh, funny, ok.
3. PHP files are the output of an XSLT transform of a bunch of XMLs... meh, seriously? Oooook.
4. XMLs are the product of the serialisation of a truck of stateful JavaEE6 DTOs populated magically (undocumented) with data coming from a SQL DB... WTF mode!!!
5. Session logics lives within PHP-land at point 2, front end makes ajax calls here that propagates to another WS out of our control that triggers -somehow- (undocumented) our Java backend at point 4 to generate new XMLs and then reach front end again. Kill me now.
Boss: look... it's too slow for the client, it's too heavy on our servers: fix it. Ah, and we sold 85% test coverage by October. You're the man for the job. (I'm a Node.js fullstacker and right now there's not even a testing scaffold, ofc).
Me: prod is on Linux or Windows?
Boss: RHEL7.
Me: rm -rf / as root. Done.
Boss: I know I know...
Me: ...
I think time has come...6 -
I am a senior a DevOps engineer who took the production stack down for ~10 minutes today because of a bad code commit. I could use some encouragement! It’s a fierce world of competitive engineers and I wonder why my company doesn’t replace me. The mistake was missed by two other peer reviews... but that doesn’t stop me from feeling this way.
Have you crashed prod? Did your team support you or tear you down?14 -
Have a couple I want to air today.
First was at my first gig as a dev, 4-5 months out of school. I was the only dev at a startup where the owner was a computer illiterate psycopath with serious temper tantrums. We're talking slamming doors, shouting at you while you are on the phone with customers, the works...
Anyways, what happened was that we needed to do an update in our database to correct some data on a few order lines regarding a specific product. Guess who forgot the fucking where-clause... Did I mention this boss was a cheap ass, dollar stupid, penny wise asshole that refused to have anything but the cheapest hosting? No backups, no test/dev/staging environment, no local copies... Yeah, live devving in prod, fucking all customers with a missing semi-colon (or where clause).
Amazingly, his sheer incompetance saved my ass, because even if I explained it, he didn't get it, and just wanted it fixed as best we could.
The second time was at a different company where we were delivering managed network services for a few municipalities. I was working netops at that time, mostly Cisco branded stuff, from Voice-over-IP and wifi to switches and some routing.
One day I was rolling out a new wireless network, and had to add the VLAN to the core switch on the correct port. VLAN's, for those who don't know, are virtual networks you can use to run several separated networks on the same cable.
To add a VLAN on a Cisco switch one uses the command:
switchport access vlan add XYZ
My mistake was omitting the 'add', which Cisco switches happily accept without warning. That command however can be quite disruptive as it replaces all of the excisting VLAN's with the new one.
Not a big deal on a distribution switch supplying an office floor or something, but on a fucking core switch in the datacenter this meant 20K user had no internet, no access to the applications in the DS, no access to Active Directory etc. Oh and my remote access to that switch also went down the drain...
Luckily a colleague of mine was on site with a console cable and access to config backups. Shit was over within 15 minutes. My boss at that time was thankfully a pragmatic guy who just responded "Well, at least you won't make that mistake again" when we debriefed him after the dust settled. -
School gave me 3 DigitalOcean droplets to try out Kubernetes in the cloud, awesome!
Wrote an Ansible script to not only simply install docker and add users but also add kubernetes, nice!
Oh wait, error?! Well I should've known this wasn't going to be easy... ah well no problem. Let's see... Ansible is cryptic as always, it can't connect to the API server? Is it even running?
Let's ssh to the master, ah nothing is running, great. Let's try out kubeadm init and see what happens, oh gosh, my Docker version has not been validated! No problem, let's just downgrade!
How do I do that? Oh I know, change the version in the role! Wait that version doesn't exit? Let's travel to Docker's website and see what versions exist of docker-ce, oh I see, it needs a subversion, no problem.
Oh that errors too? Wait then what... Oh I need a ~ and a ubuntu and a 0 somewhere, my mistake!
Let's run it again! Fails!
Same ssh process, oh wait...
Oh god no...
Kubernetes requires 2 cores and these things only have 1...
Welp, time to ask the teachers to resize my droplet by a small amount tomorrow, hopefully I'll get a new error!
----------------------------------------------
My adventure so far with Kubernetes. I'm not installing it for any serious/prod reason, just for educational purposes. K8s seems like 'endgame' to me, like one of the 'big guys' that big enterprises use so I'm eager to throw stuff at a droplet and see what happens.
Going further down the rabbit hole tomorrow!
Wish me luck :3
(And yes, I could've figured this all out beforehand with documentation, but this is more fun in my opinion)8 -
On my project the customer has re-signed into a contract several times when they have budget to continue work. The first time they got us to build the system was a huge success story because the team was assembled quickly and we did rapid development. Initialize repo to prod in 1.5 months. The customer asked for the same dev team. Strong dev team, a PM that doesn't take shit, and pure agile. Lets call her don't-take-shit PM.
When the customer re-signed the executive decided that she didn't like don't-take-shit PM. So the project manager gets replaced by play-by-the-rules PM who will comply with stupid requests and micromanagement. He isn't a bad PM but he tries to make everyone happy. The amount of management types executive installs on the project is massive, and development team is cut down in major ways. Customer and executive shit rolls down to the development team and we can't get anything done. The customer starts to lose faith because we can't get traction. They start demanding traditional waterfall/SDLC docs. Which causes more delay in the project.
So the executive decides that the PM can take a fall for it to save face for the company. She moves play-by-the-rules PM to another project. He starts handover to a new PM that has a history of being her pushover. The customer hadn't seen him yet so now we have push-over PM.
Play-by-the-rules PM is finally out of the project and instead of moving to a different account the company decides to "lay him off because there is no work". So basically they made him take the fall for the failure while promising reassignment, and instead let him go. This is so unfair..
Meeting with push-over PM yesterday and he shows us his plan. Identical to play-by-the-rules PM's plan that got him axed.We point that out and show him the docs that were made for it. His face clearly communicates "OH SHIT WHAT DID I SIGN UP FOR?"1 -
Instead of coffee to start your morning, try prod going down on Saturday! It will really get your blood pumping!2
-
Yesterday night, pushed code that work normally to prod server, website down, internal server error, too many connection to MySQL server, tried to fix it for 4 hours, nothing to do, removed the new code, still the same problem, in my head, I told myself that I'm not good at programming (not the first time), send an email to the host, they tell me the problem is from them and they fixed it. And now I know I'm not bad enough.2
-
I didn’t turn down a dev freelance project when the client decided against going with best practices because the solution I offered was a well-established design pattern but created a need for a financial management change she didn’t like. I stupidly built what she asked for. It worked fine in the 3rd party vendor test environment but failed on production. After hours of analysis of code to ensure no changes happened to my source during test->prod deployment, and the vendor denying they had config differences between them, and the client refusing to pay, all I could do was abandon the project.2
-
Dear IT troll: I am not some idiot user. I FUCKING WRITE SOFTWARE! I actually CREATE CAPABILITY! I don't create "content", I'm not some fucking suit that pumps out PowerPoint/Excel/Email all day long. I don't need to be handed a consumers screwdriver, hammer, and wrench set. I need to be able to set up the technological equivalent of MY OWN FUCKING FORGE AND ANVIL! Do you get it? Do you understand me? Give me administrator access and go the fuck away. While you're at it, please quarantine this pile of silicon onto a limited access network if it makes you feel better. My development system doesn't need to connect to the wealth of bullshit in your precious little dumbed down corporate Wiki-wannabe Sharepoint system. Keep my creative space away from Test and Prod networks while you're at it. Just give me the goddamed tools I need to do my work and fuck off!8
-
1 Week ago I took down the development version of an internal demo, leaving only the prod one (temporary space issue). Colleagues were told n+15 times via email, face to face, comments on tickets etc. The prod one has also been live for weeks, and again, they were told when it went up.
This just happened:
Colleague 1: practiseSafeHex can you help me, the demo doesn't seem to be working.
Me: *logs in*, *click around* ... seems fine dude. Are you using the correct URL: <prod-url>.
Colleague 1: let me try again and see.
Colleague 2: practiseSafeHex i'm with Colleague 1, were trying to use the demo, and its not working. Can you have a look, we need it.
Me: I just told him, its fine, I think you have the wrong URL <prod-url>. Can you try again.
Colleague 2: No I have the right one, can you check it.
Me: *does nothing*, yep i've had a look at it, can you try again: <prod-url>.
Colleague 2: Ah its back now, cheers.
They are with a customer now, so I won't say anything, when they get back, one of them is being castrated. -
I hate having to deal with our IT service desk. Every time it takes enormous energy to get to the right people and make them understand that no, you are not an idiot, but you actually have a technical issue.
Sure thing they do have a few competent nice folks there too I've gotten to know over time and they indeed have to deal with a ton of dumb non-tech savvy idiots on a daily basis. However, if my job title mentions "software" and "engineer" they should at least assume I'm an idiot in tech. Or something. Every single time I need to open a ticket, even for the simplest "add x to env y", I need to quadruple check that the subject line is moron-friendly because otherwise they would take every chance to respond "nah we can't do that", "that's not us", or "sry that's not allowed". And then I would need to respond, "yes you do:) your slightly more competent colleague just did this for us 2 weeks ago".
Now you might imagine this is on even another level when the problem is complex.
One of our internal apps has been failing because one of the internal APIs managed by a service desk team responds a 500 status code randomly but only when called with a specific internal account managed by another service desk team.
(when I say "managed by", that doesn't mean they maintain it, it just mean they are the only ones who would have access to change something)
Yesterday I spent over a fucking hour writing a super precise essay detailing the issue, proving a million times it's not on our end and that they need to fix it. Now here is an insight to what beautiful "IT service" our service desk provides:
1) ticket gets assigned to a "Connectivity Engineer" lady
2) few hours later she responds and asks me to give her the app and environment IDs and grant her access to those
(naturally everything in my email was ignored including these two IDs)
3) since the app needs to be in prod for the issue, I make a copy isolating the failing part and grant her access to the original "for reference" and the copy to play with
4) few hours later I get an email from the env that some guy called P made changes to the actual app, no changes to the copy
(maybe they immediately fixed the app even though I asked them to only touch the copy)
I also check the env and the live app had been shared with another 2 people giving them editing rights:)
5) another few hours pass and the lady responds that she had been chatting with P (no mention of who tf that guy is) and that P has a suggestion that might work and I should test it, "please see screen shot" for details:
These motherfuckers sent me a fucking screenshot of the env config file where "P has edited a few parameters" that might help. The screenshot had a 16 line part of the config json with a bunch of IDs and Base64 params which HE EDITED LOCALLY.
Again, because I needed a few iterations to realise what I've just witnessed:
These idiots modified some things in the main app (not the copy) for hours. Then came to the conclusion that the config needs some IDs and params updated. They downloaded the config json. Edited it locally. Did not fucking upload it back to the main or test app. Did not test it live. Did not CC in or direct the guy with changes to me. Did not send me the modified config file. Did not even paste the new IDs into the email. But TOOK A FUCKING SCREENSHOT OF THE MODIFIED FILE AND SENT THAT SHIT TO ME. And then had the audacity to ask me to test it when they had access to it and that's literally their fucking job.
I had to compare the fucking screenshot to the live config file and manually type in the changes.
And no, it still doesn't work. And Now I have to get back to them showing it still fails the same way but I just can't deal with these people. Fuck. Was hoping by the time I write it all down it'd be better, and it does feel a bit better, but I still need to get this app fixed. And I can only do it through these... monkeys. I just can't. Talking to these people drains my life energy... I'm just sad. -
When you raise a ticket with your support team that your prod server is currently down and they mark it as a medium request, like dude... seriously?! Get it sorted ASAP paleaaaaase4
-
A loooong time ago...
I've started my first serious job as a developer. I was young yet enthusiastic as well as a kind of a greenhorn. First time working in a business, working with a team full of experienced full-lowered ultra-seniors which were waiting to teach me the everything about software engineering.
Kind of.
Beside one senior which was the team lead as well there were two other devs. One of them was very experienced and a pretty nice guy, I could ask him anytime and he would sit down with me a give me advice. I've learned a lot of him.
Fast forward three months (yes, three months).
I was not that full kind of greenhorn anymore and people started to give me serious tasks. I had some experience in doing deployments and stuff from my other job as a sysadmin before so I was soon known as the "deployment guy", setting up deployments for our projects the right way and monitoring as well as executing them. But as it should be in every good team we had to share our knowledge so one can be on vacation or something and another colleague was able to do the task as well.
So now we come to the other teammate. The one I was not talking about till now. And that for a reason.
He was very nice too and had a couple of years as a dev on his CV, but...yeah...like...
When I switched some production systems to Linux he had to learn something about Linux. Everytime he encountered an error message he turned around and asked me how to fix it. Even. For. The. Simplest. Error. He. Could. Google. Up.
I mean okay, when one's new to a system it's not that easy, but when you have an error message which prints out THE SOLUTION FOR THE ERROR and he asks me how to fix it...excuse me?
This happened over 30 times.
A. Week.
Later on I had to introduce him to the deployment workflow for a project, so he could eventually deploy the staging environment and the production environment by hisself.
I introduced him. Not for 10 minutes. I explained him the whole workflow and the very main techniques and tools used for like two hours. Every then and when I stopped and asked him if he had any questions. He had'nt! Wonderful!
Haha. Oh no.
So he had to do his first production deployment. I sat by his side to monitor everything. He did well. One or two questions but he did well.
The same when he did his second prod deploy. Everythings fine.
And then. It. Frikkin. Begins.
I was working on the project, did some changes to the code. Okay, deploy it to dev, time for testing.
Hm.
Error checking out git. Okay, awkward. Got to investigate...
On the dev server were some files changed. Strange. The repo was all up to date. But these changes seemed newer because they were fixing at least one bug I was working on.
This doubles the strangeness.
I want over to my colleague's desk.
I asked him about any recent changes to the codebase.
"Yeah, there was a bug you were working on right? But the ticket was open like two days so I thought I'll fix it"
What the Heck dude, this bug was not critical at all and I had other tasks which were more important. Okay, but what about the changed files?
"Oh yeah, I could not remember the exact deployment steps (hint from the author: I wrote them down into our internal Wiki, he wrote them done by hisself when introducing him and after all it's two frikkin commands), so I uploaded them via FTP"
"Uhm... that's not how we do it buddy. We have to follow the procedure to avoid..."
"The boss said it was fine so I uploaded the changes directly to the production servers. It's so much easier via FTP and not this deployment crap, sorry to say that"
You. Did. What?
I could not resist and asked the boss about this. But this had not Effect at all, was the long-time best-buddy-schmuddy-friend of the boss colleague's father.
So in the end I sat there reverting, committing and deploying.
Yep
It's soooo much harder this deployment crap.
Years later, a long time after I quit the job and moved to another company, I get to know that the colleague now is responsible for technical project management.
Hm.
Project Management.
Karma's a bitch, right? -
Worst prod scenario experienced - on site in small African country working on CRM/billing system my colleague was testing some new SQL and after finishing decided to drop and recreate the DB. She thinks the process is very slow and suddenly realizes she is dropping the prod DB. In a panic she shuts down the system and starts doing a restore from tape, but is so stressed out she writes "tar cv" instead of "tar xv" and overwrites the backup with the broken DB. Took a while to clean that one up...2
-
Today I had my first ever prod db fuckup due to too wide where clause in delete query. Spent 8 hours restoring service. It's 02.09 now and I'm finally home, going to bed.
Interestingly enough I've enjoyed this experience... -
I'm currently between jobs and have a few rants about my previous job (naturally). In retrospect, it's somewhat therapeutic to range about the sheer brainfuckery that has taken place. Enjoy!
First, let me set the scene: legacy B2B web app made with LEMP stack and sencha ext.js 3 + 4 (don't ask) and a lot of madness. Let's call that app "Alpha".
Alpha is a self made CMS build for typical ERP stuff. Yes, a self made CMS: entities are containers, containers have types and fields and values. Like so many legacy PHP apps, it does not have a dedicated FE: the HTML is rendered on the server and then spewed out to the browser.
Easy right? Coding like it's 1999! But there was a twist: Because everything is basically a container, the HTML-templates are saved in the DB. Along with the nessary JS and the CSS. And the translation variables. Why? Because fuck you! That's why. Who needs a git history anyways.
For some reason, Alpha was kinda slow.
There was also an editor, that allowed you to modify templates (web, mail, pdf) on the fly in prod. Because templates contain repeating data (header/footer), one template could contain additional templates. Much confusion. You could change templates via migration (slow, boring) or just ctrl-c/ctrl-v that sucker (fast, much excitement).
Did I mention Alpha was slow?
On with the rant: e-mails! How do they work? Noone knows. How to send mails asynchronous in PHP? Witchcraft is the only possible answer to that riddle. Here is your enterprise™ solution:
1. create mail
2. insert mail into DB
3. WAIT UP TO 59 SECONDS FOR A FUCKING CRON TO SEND MAIL
Why? "Because that way, we can resend mails in case the network is down :)"
Same procedure for the SOAP-API (db-queue + cron). You read that right: all requests to various other systems are processed once a minute.
Alpha slow.
Alpha was only one of several systems. Imagine a bunch of monolithic php apps, interconnected via SOAP, REST and GraphQL like a godamn intergalactic orgy. Image having to debug that cluster fuck.
Let's say there is a bad request. These things happen. No biggie. Remember the db-queue? Let's try to send the bad request a second time! And a third time! Still no luck? How odd. Let's create a specific file in a specific directory: a LOCK-file. Now, "the db-queue is on hold and no request gets processed :)"
Golly gee thanks Alpha.
Anyhow, did you know that MySQL has a join limit of 61 tables?
3 -
Lessions I learned so far from my first big node/npm project with tons of users:
1) If you didn't build something for a while, expect 3 hours of resolving version conflicts for every two weeks since the last build.
2) Even if the tests pass, run the containers on your own machine and make sure that the app doesn't randomly crash before deploying
3) Even if the app seemed to work on your own machine, run the tests again in an environment mimicking prod at most 15 minutes before replacing the running containers.
4) Even if all else indicates that the app will work, only ever deploy if you expect to be available within the 4 hours following a deployment.
5) Don't use shrinkwrap for anything other than locking every version down completely. A partial shrinkwrap will produce bugs that are dependent on the exact hour you built the app _and_ the shrinkwrap file, and therefore no one will ever have seen them other than you.
6) Avoid gyp, and generally try not to interface too much with anything that doesn't run on node. If parts of your solution use very different toolchains, your problems will be approximately proportional to the amount of code. And you'd be surprised just how much code you're running. (otherwise it's more logarithmic because the more code the less likely a new assumption is unique)
7) Do not update webpack or its plugins or anything they might call unless you absolutely need to
8) Containers are cool but the alpine ones are pretty much useless if you have even just one gyp module.
9) There's always another cache. To save yourself a lot of pain, include the build time in every file or its name that the browser can download, and compare these to a fresh build while debugging to assert that the bug is still present in the code you're reading
+1) Although it may look like it, SQLite is far from a simple solution because the code and the bindings aren't maintained. In fact, it'll probably be more time consuming than using a proper database.3 -
Two (2) senior developers and one (1) senior tester left our team and I am left with two (2) Java legacy applications that are hard to maintain. Here is a list of things I hate about these old webapps (let's call them app A and B):
1. App A depends on 80% web services. If one web service for a product or warehouse goes down, work flow is impeded while prod support team checks with the core services team for repair
2. App B is a maven project with multiple modules dependent on libraries that are dependent on company's internal libraries. So if we want to upgrade to OpenJdk 9 and up, the project will definitely produce a lot of errors due to deprecated/unsupported codes
3. App A is dependent on Tibco and I have no experience on that
4. App B's continuous integration build tool is Jenkins and the jobs that build it has a shell script that wasn't updated during the tech upgrade enhancement. The previous developer who did the knowledge transfer to me didn't tell me about this (it should be considered a defect on her part but she already resigned)
5. App A when loaded in eclipse IDE is a pain to work with since it is only allowed to build a war file using ant. I have to lookup in quick search instead of calling shortcuts (call hierarchy) because the project wasn't compiled via eclipse.
6. It's impossible to debug app A because of #5
7. Both applications have high priority and complex enhancements and I have no other teammates to help me
8. You never know what else can go wrong anytime1 -
Finally made my node production server stable enough that I could focus on writing tests*. I start by setting up docker, mocking cognito, preparing the database and everything. Reading up on Node test suites and following a short tut to set up my first unit test. Didn't go smoothly, but it's local and there are no deadlines so who cares. 4 days later, first assert.equal(1+1, 2) passes and I'm happy.
I start writing all sorts of tests, installing everything required into "devDependancies," and getting the joy of having some tests pass on first try with all asserts set up, feels good!
I decide to make a small update to production, so I add a test, run and see it fail, implement the feature, re-run and, it passes!
I push the feature to develop, test it, and it works as intended. Merge that to master and subsequently to one of my ec2 production servers**, and lo and behold, production server is on a bootloop claiming it "Cannot find module `graphql`". But how? I didn't change any production dependencies, and my package lock json is committed so wth?
I google the issue, but can't find anything relevant. The only thing that I could guess was that some dependencies (including graphql) were referenced*** in both, prod and dev, and were omitted when installed on a prod NODE_ENV, but googling that specific issue yielded no results, and I would have thought npm would be clever enough to see that and would always install those dependencies (spoiler: it didn't for me).
With reduced production capacity (having one server down) I decided to npm uninstall all dev dependencies anyway and see what happens. Aaaaand it works.....
So now I have a working production server, but broken local tests, and I'm not sure why npm is behaving like this...
* Yes I see the irony.
** No staging because $$$, also this is a personal project.
*** I am not directly referencing the same thing twice, it's probably a subdependency somewhere.2 -
OMG you fucking dick! All I asked if you minded if I created a PR to push your branch to prod because test was down.
You didn’t have to bother the fucking software architects in a group chat with me saying I needed fucking help.
If you wrote the isset function correctly to begin with or even put the JSON file in the correct repo like every other file on the site this would not be a problem.
Fuck contractors! Fuck Assholes!2 -
Last day at work: goodbye overnight sessions breeding over some arcane legacy code that blew up in prod or manually restoring dozens of backups because the customer continued to work while systems went down due to power failure.
Colleagues last commit message at that place: It just works (Friday 8pm then shipping the code to prod)2 -
My Stunt of the day:
People say avoid deployment on Fridays.
I strictly followed it and being a nocturnal creature, just pushed my code to Prod and it's Saturday early morning.
Deployment taking forever. Gonna sleep now.
I hope nothing goes down.2 -
Out of the frying pan, into the fire:
So in my first job, I thought it's just us operating so crazy: meddling with arcane C/C++ code from the 80's, shooting our code to production without testing, fixing hundred of customers data base entries by hand, letting an intern alter some core component (to have more logging) and directly push it to prod...
Silly me.
I mean I suspected, that maybe it's not only this tiny little company acting wild, that also the bigger companies with all their ISO certified processes, agile blabla, professional tooling whatsoever - will also have their skeleton in the closet,.. like some obscure assembler part buried in the heart of your code base nobody dares to touch...
How Pieter Hintjens asked about the state of the industry and all the fads so bluntly put it:
"It's all bullshit."
But we are humans, so we better jump on the bandwagon if we want to keep our jobs... and somehow try to keep that trashy house of cards from crashing down. -
Well, this happens time to time...
I'm freelancing as a backend guy. I like to take care of all infrastructure before really starting to build anything, this mostly includes dev/staging/prod environments with some linear promotion strategy. So.. I did this API. Still on staging, proceeding with the development as planned, everything goes according the timeline.
And then.. this happens... At some point PM told frontend guy that it's time for production (without notifying me), so the frontend guy does what "anyone" would do in this case - tells PM to create DNS record for production to point to staging app.
Time passes, I'm still unaware of this. But I'm starting to see some quality entries in the DB, not the usual QA crap. I write to them that they're doing good job and continue with my tasks.
One of the tasks required some major DB change. I could've written migrations script, but since we're not in "production" yet, I just wipe the DB and recreate schema as I need it.
In 10 minutes the furious PM starts shouting that "production" is down and I need to fix it ASAP.
I'm lost, I'm asking questions, I'm slowly understanding what's happening...
So I want to grab some coffee, sat back down, wrote politely that they suck, added a finger emoji and terminated the contract.
Felt like the right thing to do as I definitely don't want to continue within the same "team".1 -
Losing faith in Netflix and their awesome open source projects.
Had a hard time trying to install Security Monkey : poor quality quickstart Ubuntu-only, almost no documentation, same instructions for latest (aka dev) and stable (aka prod) version, no depencies list ... oh and the UI display well only on Chrome ..
Then you surrender and just want to check the dockerized version they provide : it doesn't work neither (build fail or back end process just shut down) !!
I'm done ... -
If a team uses multiple languages and stacks (Have, JS, Python) do you think it's better to have everyone use/constantly switch between them or have dedicated developers for each language (ie. 80% main, 20% others)?
--END QUESTION, ANSWER NOW BEFOREHAND CONTINUING---
---BEGIN RANT---
My boss likes keeping the team "will rounded" so everyone does everything. One month in working in Java, the next with Node web apps. When I switch to node, it takes like a week of "wtf doesn't it work.... what changed, is it a big?" And usually end it"oh right I remember I need to ..."
And also always... "How the fuck do I write tests in {some reading framework} again?"
So feels like everyone is just a generalist and no one is a master/has time to develop mastery. I don't know if it's just me (1/3 Senior developers on the team that has to do everything) or if I'm the only one that complains... Not that it makes a difference... (Only option to really be heard is to resign but I need to somewhere else to work and finding one is hard for personal reasons)
And well this is the biggest reason I would leave the team. No time for mastery, no standardization/shared knowledge (everyone does their own thing but probably not well and no time for testing or documentation; how the fuck does whatever you wrote work, how do we use it, what the fuck did you put in prod that does ... And where the fuck did you put it cuz it's not in ANY of our repos).
I always feel one day soon it will come crashing down and I can say "I told you so" but will then it's too late and I'll be there one cleaning it up... Again6 -
Had a client whom was using the staging system on my server as cdn, remote computing, etc... because his prod server was a cheap vhost while the vm was a beast compared to it. I shut it down without telling. I just got a call that his site is now slow a f and full of errors.
I kindly told him that there was a recent security breach called dirty cow. Then I told him that I shut the vm down because it would mean security risk for him since there are no patches available yet and only Power on again with there was work for me to do.
If you want resources pay for them -
Long post, TLDR: Given a large team building large enterprise apps with many parts (mini-projects/processes), how do you reduce the bus-factor and the # of Brent's (Phoenix Project)?
# The detailed version #
We have a lot of people making changes, building in new processes to support new flows or changes in the requirements and data.
But we also have to support these except when it gets into Production there is little information to quickly understand:
- how it works
- what it does/supposed to do
- what the inputs and dependencies are
So often times, if there's an issue, I have to reverse engineer whatever logic I can find out of a huge mess.
I guess the saying goes: the only people that know how it works is whoever wrote it and God.
I'm a senior dev but i spend a lot of time digging thru source code and PROD issues to figure out why ... is broken and how to maybe fix it.
I think in Agile there's supposed to be artifacts during development but never seen em.
Personally whenever i work on a new project, I write down notes and create design diagrams so i can confirm things and have easy to use references while working.
I don't think anyone else does that. And afterwards, I don't have anywhere to put it/share it. There is no central repo for this stuff other than our Wiki but for the most part, is like a dumping ground. You have to dig for information and hoping there's something useful.
And when people leave, information is lost forever and well... we hire a lot of monkeys... so again I feel a lot of times i m trying to recover information from a corrupted hard drive...
The only way real information is transferred is thru word of mouth, special knowledge transfer sessions.
Ideally I would like anything that goes into PROD to have design docs as well as usage instructions in order for anyone to be able to quickly pick it up as needed but I'm not sure if that's realistic.
Even unit tests don't seem to help much as they just test specific functions but don't give much detail about how a whole process is supposed to work.9 -
We have our product's second release this week. And my manager was like... I don't want anyone to be absent in the coming days.
But he concluded the pep talk with an announcement that he is off work for the next 5 days.
I think he meant - idgaf even if our PROD burns down before I return !! -_- -
//rant
Two weeks ago we delivered four parts from a request containing about 30 minor developments to ease general every day operations.. this week my boss demanded a specified fallout report about how those cut our expenses and costs, how many percentage those four of the total amount of savings all 30 developments would save and whatnot.
ARE YOU FUCKING SHITTING ME!? They've been in prod for ONE god damn week and the intended operations are not even launched yet! How about you go and CHILL THE FUCK DOWN!? I understand that whole part about growing business and getting it to stay alive, but you sir.. you.. GAAAH!! -
Half a day wasted. FUCK!
I use grafana loki and mimir/prometheus for telemetry. A few days ago I queried loki to see if logging is still working. Yesterday I changed the datasource to mimir, changed the query parameters to get metrics from another env, ran the query, and... Querier [mimir] crashed.
Wtf.
Error says it got too much data to chew on.
So I spend 4 hours playing with the querier and grpc limits, balancing between limit errors and OOMKills [2G ram].
I got suspicious about oomk. Why would it...
Then I tried to shrink the timeframe to 15min. Still oomk. Down to 5min -- now it worked. But the number of different metrics returned was over 1k
then I look once again at the query. And ofc it is ´{env="prod"}´
turns out, forgetting that you're querying metrics with a logs' query is an expensive and frustrating mistake. Esp. at 3am.
idk why it even returned me anything...7 -
Fuck my company, sincerly.
So Im crunching my ass off, to make product, there is +- fuckton of changes that for example require refactoring flow of certain things, restructure of how shit work, Im +- 2nd weekend now, and most heavy features are cleared.
I work till late. constantly I have someone with stupid shit like calls, indeed Im needed for that stuff but also, that slows down progress of this project. Just sake of example friday 18:00 I had call (I work till 16:00) about new minor and frankly easy feature. Today, morning 8:30 one call, than 13:00 long call, Ive done the feature, didn't push it to alpha. yet though.
Now during that call that started 13:00 I get yelled on that all ordered features aren't on prod yet (I throw them to alpha becouse manual tests must be done as standard here).
Dude what the motherfuck. Im literally wearing my ass off to deliver your stupid product becouse I know its critical for company but it does not mean I can do it all in one fucking night.
F**k off and shut your mouth up and let me work for f**k sakes.
Ah also, stop f**king remotely micromanage me you little piece of sh*t.
Thanx for allowing me to vent out,
Peace.2 -
I working hotfix in prod, small fix but fatal it's about environtment and proxy thing, and I forgot to write in the decumentation, 3 month after that I leave the company.
After some week the PM contact me and tell the developer create some error and make the production down, and the whole team is not going home for 3 days working on that issue.
He offer me some money for helping with the issue, I aggred and they give me some account for access the environtment and code.
I can fix it in less than 15 minutes, but because they cannot fix it I working it for 6 hour, and after that I explain the step for solving it, they seems really glad that I can solve the issue and now the prod is working again..
Now In my opinion, I know I was not a good person, and what i've done is maybe not acceptable.
But for me as a developer, as long I have the credential and access I can read(guessed) how the flow goes and know the environtment that my company use without they explain it or some googling definitly will help right.?
So, what you say about it, What will you do if you got into my situation.?10 -
So, I was googling for cross platform javascript things.. every answer, there's only weex and nativescript, but both aren't ready for prod, so I tried weex, it's alright but the documentation is non existant, and the support is practically on dial up, and hardly anyone has used it. And nativescript isn't really an option cause it's only for mobile.
So I chose weex, web + mobile, and I can easily port my already written vue project, sweet, so I get to porting, run into a few issues but it's pretty easy, need to play with some of the root file path definitions, no "./"'s just "@/" (if you use @ as your root symbol).
great. Pug works, sass... seems to work, then I run into a pretty big issue with sass compilation/loading, can't find an answer for an hour.
So I go out. Then come home, no answer on my SO question.
So I google "jsfiddle weex" to get a jsfiddle template for debugging weex/vue projects.
A few results down. I see this: https://reddit.com/r/javascript/...
well I've heard of framework7, but it would require me rewriting most of my element tags and components, but what's quasar?
I have a look, totally cross platform, desktop, web, mobile... wtf..
read the docs, "uses vue single file components"
..what, holy fuck, the documentation is beautiful, it uses vuex, fucking fuck.
I just found it 10 minutes ago....
wish me luck.........
Top Tags
Weekly Rant
View