Roughly 180 days, 5 months and 29 days, 4,320 hours, 259,200 minutes, I devoted myself to a client project. I missed family outings with my daughter and my wife. People started asking my wife if we had broken up. My daughter became accustomed to daddy not being around and playing with her. Sometimes only sleeping 4 hours, I would figure out solutions to problems in my sleep and force myself to wake and put them into action. My relationship with my wife became very fragile and unstable. I knew I had to change but I just needed a little bit more time to complete this client project.

Finally, the project was ending there was light at the end of the tunnel. I “git add –-all && git status” everything looked good. I then “git commit -m “v1.0 release candidate && git push beanstalk master”

I deployed the app to the staging server where I performed my deployment steps. Everything was good. I signed-up as a new user, I upload a bunch different files types with different sizes, completed my profile and logged out. I emailed the client to arrange a time to speak remotely.

“Hello” says the client “How are you” I replied. “Great, lets begin” urged the client. I recited the apps url out to the client. The client creates a new account and tries to upload a file. The app spews a bunch of error messages on the screen.

The client says

“Merlin – I do not think you really applied yourself to this project. The first test we do and it fails. If you do not have the time to do my project properly please just say so now, so I can find somebody else who can”

I FREAKED THE FUCKOUT on the client!!!!!!! and nearly hung up. My wife was right next to and she was absolutely gobsmacked. I sat back and thought to myself “These fuckers don’t get it”. All that suffering for nothing!

Thanks for reading my rant….

BTW: I did finish the project, the client was amazed on how the app worked and it is has become an indispensable tool for their employees.

!rant
!!git

Who here uses `master` for development?

My boss (api guy) tried to convince me that was normal practice. I gently told him that it sounded crazy and very very bad.

Here's the dev path I'm enforcing on my repos:

(feature branches) -> dev -> qa* -> master -> production*

*: the build server auto-pulls from these branches, and pushes any passing builds to staging/production.

Everyone works on their own feature branches, and when they're happy with their work, they merge it into `dev`. `dev`, therefore, is for feature integration testing. After everything is working well on `dev`, it gets merged into `qa` for the testers to fawn over and beat with sticks. Anything that passes QA gets merged into `master`, where it sits until we're ready to release it. When that time comes (it's usually right away, but not always), `master` gets merged into `production`.

This way, `master` is always stable and contains the newest code, so it's perfect for forking/etc. Is this standard practice, or should I be doing something different?

Also, api guy encourages something he calls "running a racetrack" -- each dev has their own branch (their initials) and they push to that throughout the day. everyone else pulls from it regularly and pushes to their own branch. When anyone's happy with their code, they push from their (updated) branch to `qa` (I insisted on `dev` instead.)

Supposedly this drastically reduces the number of merge conflicts when pushing to an upstream branch due to having a more recent ancestor node?

I don't quite follow that, but it seems to me that merging/pushing throughout the day would just make them happen sooner? idk.

What are your thoughts?

Always the same story:

Marketing: hey I'm gonna do a demo to a customer. They were asking for feature XYZ. That's ready on thr staging server right? Do you think I could use the staging server for the demo?

Devs: well feature XYZ is not 100% done. Basically just feature X is done, and it still has a few bugs. The deadline ain't for another month, since we gotta finish ABC first. I guess you could use the staging, but it has a lot of bugs.

Marketing: perfect!

*after presentation*

Marketing: the staging had so many bugs! Why didn't you tell me?! It was so embarrassing showing it to new customers! Anyway, they loved the new feature. We need it to be ready ASAP.

Devs: What?! That's gonna mess up with our schedule. You know what? Fine, but feature ABC will have to wait another month.

Marketing: Well, it'd be ideal if we could do both...

Devs: Pay for more devs or dor extra hours.

Marketing: Just do XYZ. It's a pity that you'll have to push back ABC but it's fine, XYZ is more important.

(I might ask, if it was so important, why didn't you notice so in the meeting where we had decided that ABC would be prioritized?)

*tons of working hours later*

Devs: There, we finished XYZ.

Marketing: Yay! Wow, this month we'll have two major features done: ABC and XYZ!

Devs: No, ABC is not done yet.

Marketing: What? But the deadline was this week.

Devs: It was, but then you decided to prioritize XYZ and we said we had to push back ABC to get XYZ ready, and you agreed.

Marketing: Did we? Fine. But do it quick.

Marketing and their mood swings.

"LeT's uSe gRaPhQL!" They said.

"It EliMinAtEs cOmpLeX aNd vErBoSe REST coDe!" they said.

Me sitting here for hours waiting for the backend team to fix major regressions every time they push the smallest "updates" to staging... 🤡

Call me a boomer but I can't help but feeling graphQL makes things MORE complex than REST... either that or the backend devs have no idea what they are doing

Me: Hi, I finished X and Y, will finish Z tomorrow and be able to push it to the staging server for you to test!
*Client 15 hours later*
Client: I don't see it, where is it?
Me: It's not there yet, I need to finish Z first, it's right now on the development server, not the testing server
Client: Yes, but I don't see it?
...

I used to work on a production management team, whose job was, among other things, safeguarding access to production. Dev teams would send us requests all the time to, "run a quick SQL script."

Invariably, the SQL would include, "SELECT * FROM db_config."

We would push the tickets back, and the devs would call us, enraged. I learned pretty quickly that they didn't have any real interest in dev, test, or staging environments, and just wanted to do everything in prod, and see if it works.

But they would give up their protests pretty fast when I offered to let them speak to a manager when they were upset I wouldn't run their SQL.

Giant, month-and-a-half-long-ticket.
After learning six or so complicated areas of the system and updating them all to work with the new changes, make them all play nicely, etc. I finally got everything working. 95% spec coverage, though no ui tests because I haven't gotten selenium working. whatever, everything's done and works.

Second dev bases her ticket off of mine and continues working. Work elsewhere continues and there's an official release, so we both merge in master. I run tests, everything passes, and go back to working on other tickets.

She finishes her ticket.
We do end-to-end testing, and everything works perfectly. Time for a demo!

She merges in master again, and pushes her branch to two staging servers. (idk why two.)

Demo starts.
We connect to the staging servers, and... none of the UI changes exist; they aren't running the correct code!

So she runs it locally for a demo instead. Two features in my ticket no longer work. She throws me under the bus. She throws me under the bus again by criticising a rake task I scrapped because she wanted to do it. Then again because I didn't update my branch to master and push it before the demo, despite having no reason to. and despite the demo being of her branch.

Then she continues to show off and brag about how she's like the "legend" (senior dev) she envies. QAbuys it.

I'm having an emotion, and it's called anger.

So after 6 months of asking for production API token we've finally received it. It got physically delivered by a courier, passed as a text file on a CD. We didn't have a CD drive. Now we do. Because security. Only it turned out to be encrypted with our old public key so they had to redo the whole process. With our current public key. That they couldn't just download, because security, and demanded it to be passed in the fucking same way first. Luckily our hardware guy anticipated this and the CD drives he got can burn as well. So another two weeks passed and finally we got a visit from the courier again. But wait! The file was signed by two people and the signatures weren't trusted, both fingerprints I had to verify by phone, because security, and one of them was on vacation... until today when they finally called back and I could overwrite that fucking token and push to staging environment before the final push to prod.

Only for some reason I couldn't commit. Because the production token was exactly the same as the fucking test token so there was *nothing to commit!*

BECAUSE FUCKING SECURITY!

Code review day 1:

Me: Where are these three templates being used? I don't see any class that uses them.

Him: Oh, yeah. My bad. I'll remove them.

(Time passes)

Him: I don't know what's going on with my branch. Please ignore the PR for now.

(Time passes)

Him: Is there any way for me to get the files from staging. I don't know what I did to my branch.

Me: Hang on. I'll push a copy of the one I have in a new branch.

He declines his PR and stops by to say he's going home but he'll open a new PR tomorrow and remove the unused files.

Code review day 2:

Him: Hey, do you know what happened to my PR? It looks like it disappeared.

Me: You declined it yesterday. Said you'd make a new one today without those extra files.

Him: Ooooh!

TL;DR: When picking vendors to outsource work to, vet them really well.

Backstory:
Got a large redesign project that involves rebuilding a website's main navigation (accessibility reasons).
Project is too big just for our dev team to handle with our workload so we got to bring a 3rd party vendor to help us. We do this often so no big deal.
But, this time the twist was Senior Management already had retained hours with a dev shop so they want us to use them for project. Okay...

It begins:
Have our scope / discovery meeting about the changes and our expected DevOps workflow.

Devs work Local and push changes to our Github, that kicks off the build and we test on Dev, then it goes to Staging for more testing & PM review. Once ready we can push to prod, or whenever needed. All is agreed, everyone was happy.

Emailed the vendors' project manager to ask for their devs Github accounts so we can add them to the project. Got no reply for 3 days.

4th day, I get back "Who sets up the Github accounts?"

fuck me. they've never used Github before but in our scope meeting 4 days ago you said Github was fine...??

Whatever, fuck it. I'll make the accounts and add them.

Added 4 devs to the repo and setup new branch. 40min later get an email that they can't setup dev environment now, the dev doesn't know how to setup our CMS locally, "not working for some reason."

So, they ask for permission to develop on our STAGING server.. "because it's already setup"... they want to actively dev on our staging where we get PM/Senior Management approvals?

We have dev, staging, production instances and you want to dev in staging, not dev?... nay nay good sir.

This is whom senior management wants us to use, already paid for via retainer no less. They are a major dev shop and they're useless...

😢😭

Cant wait for today's progress checkup meeting. 😐😐

/rant

I am so fucking drunk but still I ended up completing a task which is a feature request.... I have no idea how I did it... But it works in staging... That's what I remember.... Will see tomorrow.... I am also the tester in the hierarchy which starts and ends with me... I don't know whether this qualifies as a rant

So in the project I’m working on we were about to do a push to live, no major functionality just minor adjustments and nice to have stuff. One of the things I did was a reminder, nothing special just sends an email out if something hasn’t been done for 3 days and then sends an email every day following. Push to live and every thing goes fine with no issues. Day 1 there are no issues. Day 2 there are no issues. Day 3 and I’m inundated with people telling me that the emails are getting sent to practically everyone, shit. What have I done? What have I missed?
So I start looking at the live database hoping for a data problem, no such luck. I look at my code looking for something blatantly obvious but nothing. I start replicating the data but I can’t reproduce this bug and it’s annoying the hell out of me. I checked one of the emails that the client sent to us more thoroughly and seen that it was sent at 07:01. This is odd as our webjob runs at 1am so I start looking at environmental factors and started looking at release management, more out of hope than expectation. I check the staging environment and see that the webjob ran at 7:00. Coincidence I thought, the webjob gets packaged on the release pipeline and everything in the database was dummy data anyway but I’d better check anyway. The database was an exact copy of the live database, turns out a “senior developer” wanted to sanity check everything by running live data through the code so he copied the database over. It was fine for the first couple of days but the data was now 3 days out of date triggering my email code and I get hit with the shit storm. I’ve never met such an incompetent developer in my fucking life, functions 700 lines long, classes that are over 20000 lines, repetition every where and the only design patterns he’s used is when he picks up a child’s colouring book. I can live with the fact that he writes code like someone on their first day of University But copying a database because he wants to “visualise” the fucking data is absolutely farcical. No wonder the project is fucked with a “developer” (in the loosest possible use of the word) is at the helm.

First rant here..

So earlier this week, on a php Laravel project, I created a set of nice new features.

The code is tested, locally all fine, I push to Github, circleCi kicks in and double checks myself, still everything green. (Just for a not, its a private project so only I work on it.)

I go ahead and merge, deploy to staging and continue on my next ticket, which is a very small one.

I call it the day, next day I pick back up where I left, test locally, all green, push... then circleCi says no.

I spend 2 days debugging, trying to figure out what is wrong without advance. I just push develop branch again, guess what also failing.

I leave it for the day as I already spend enough time on it.

This morning, I simply do a composer update, push and everything miraculously starts working.. even if there were no changes in the working branches.

Im so mad right now, and this is going in my "try this before you debug a ci" book..

I deployed one of our staging websites to a free plan because the site is rarely used. Project Manager sends the stakeholders the new url. There will be a lot of 🤦‍♀️🤦‍♂️🤦 all around. Some of it’s my fault. A lot of it is just WTF.

Stakeholder: We still need the staging site because we don’t want to test in the live site…

PM: Okay. We didn’t say we were deleting the site. We are just moving it to a new and better hosting platform, so we’re letting you know the url has changed.

Stakeholder: This url is for the front facing page. How do I access the backend? [they mean the admin interface]

Me: The only thing that’s changed is the url for the staging website. So domain-A/account is now domain-B/account.

I thought that was a pretty straightforward way of explaining things, that even a non technical person would get it. They took the /account example as the literal login url.

Stakeholder: I forgot the password for our admin login and I submitted a password reset, but I realize I don’t know if I have access to the admin email. Or if it’s even a real email account.

WTF

I look back at the email chain and I realize that I gave the PM the wrong url.

Also, WTF x 2. How did this stakeholder not realize they were looking at the wrong website?? There are definitely noticeable style and content differences. And why would you have an admin login that uses a fake email??

Me: My apologies. I sent over the incorrect url. My instructions are mostly the same. All that’s changed is the domain.

Stakeholder’s assistant: [DMs me] How do we access the backend?

WTF…are they seriously playing this game and demanding I type out the url for them?! 🤬 I’m not playing this game and I just copy and paste the example that I already sent over.

They figure it out eventually. Apparently, they never used /account to login before They used /admin/index… but that would still bring them to /account, but with ?redirect=/admin/index appended to the url if they weren’t logged in. Again, WTF.

I know I made mistakes in this whole thing, but damn. I can’t even. I’m pretty sure this whole incident is fueling my boss’s push to stop supporting this particular website anymore so I can focus on sites that actually bring in revenue…and have stakeholders that aren’t looney and condescending like this.

Debugging WebRTC is pure hell.

For starters, it's JavaScript, so you know this isn't gonna end well. Second, it's still in kinda beta phase for some browsers so you gotta add polyfills. Let's talk compatibility now. During normal days, yeah, I could ask for a couple of computers in the office, each using a different browser. But, covid. One browser mishbehaves and doesn't wanna share the camera with the other browser, so I can't really test a connection with the only 1 computer I have. I can't take my partner's computer all day to debug.

Solution: ask the marketing department or even the execs to video chat with you to test it on a staging server. So I push my changes to the server, wait for them to build, call my lab rat, check all the bugs, clean the code, push the changes back up. No fancy breakpoints. I'm doing the old style like my great uncle did. Oh wait no, he was pretty intelligent, but my lab rat isn't. They probably don't know what a console is. So no baby I'm not only talking about console logging the problems, I'm talking `alert` the heck out of the bugs - okay no, I'll just display the objects in the middle of the screen. The screen is my console.

Long story ahead

Background:
I recently started a job in a smallish startup doing web development in a mostly js stack as an entry-junior engineer/dev. I’m the only person actively working on our internal tools as my Lead Engineer (the only other in house dev) is working on other stuff.

Now I was given a two week sprint to rebuild a portion of our legacy internal app from angular 1.2 with material-ui looking components with no psd’s or cut-outs of any kind to a React and bootstrap ui for the front end and convert our .net API routes into Node.js ones. I had to build the API routes, SQL queries (as there were plenty of changes and reiterations that I had to go through to get the exact data I needed to display), and front end. I worked from 9am until 11pm every day for those two weeks including weekends as our company has a huge show this upcoming week.

I finish up this past sunday and push to our staging environment. The UI is 5.5/10 as we’re changing all of our styling to bootstrap and I’m no ui expert. The api has tests and works flawlessly (tm).

So we go into code review and everything is working as expected until one tab that I made erred out and was written down as a “Needs to be fixed.”

This fix was just a null value handler that took three minutes and a push back to staging, but that wasnt before a stupendous amount of shit being flung my way for the ui not looking great and that one bug was a huge deal and that he couldnt believe it slipped through my fingers.

Honestly, I’m feeling really unmotivated to do anything else. I overworked myself for that only to be shit on for one mistake and my ui being lack-luster with no guides.

Am I being a baby about this or is this something to learn from?

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.

"You shouldn't mark things as done if they aren't. It's only done when I can see it on the server and demo it."

Well, I just demoed it to you, you prick. The fact that it's not running on a server is because that AWS endpoint we have there is no where near being able to be called "staging" even, mainly because the other dev on the team hasn't committed their work in 8 days, let alone push it to said server. Data models have changed, APIs have changed, hell, the god forsaken Sahara desert is now green and blooming as far as I'm concerned.

So instead of trying to look smart to your boss, why don't you ask first you obnoxious waste of organic matter. Stop breathing our oxygen for once. There are more useful things to do with it.

After three months of development, my first contribution to the client is going live on their servers in less than 12 hours. And let me say, I shall never again be doing that much programming in one go, because the last week and a half has been a nightmare... Where to begin...

So last Monday, my code passed to our testing servers, for QA to review and give its seal of approval. But the server was acting up and wouldn't let us do much, giving us tons of timeouts and other errors, so we reported it to the sysadmin and had to put off the testing.

Now that's all fine and dandy, but last Wednesday we had to prepare the release for 4 days of regression testing on our staging servers, which meant that by Wednesday night the code had to be greenlight by QA. Tuesday the sysadmin was unable to check the problem on our testing servers, so we had to wait to Wednesday.

Wednesday comes along, I'm patching a couple things I saw, and around lunch time we deploy to the testing servers. I launch our fancy new Postman tests which pass in local, and I get a bunch of errors. Partially my codes fault, partially the testing env manipulating server responses and systems failing.

Fifteen minutes before I leave work on the day we have to leave everything ready to pass to staging, I find another bug, which is not really something I can ignore. My typing skills go to work as I'm hammering line after line of code out, trying to get it finished so we can deploy and test when I get home. Done just in time to catch the bus home...

So I get home. Run the tests. Still a couple failures due to the bug I tried to resolve. We ask for an extension till the following morning, thus delaying our deployment to staging. Eight hours later, at 1AM, after working a full 8 hours before, I push my code and leave it ready for deployment the following morning. Finally, everything works and we can get our code up to staging. Tests had to be modified to accommodate the shitty testing environment, but I'm happy that we're finally done there.

Staging server shits itself for half a day, so we end up doing regression tests a full day late, without a change in date for our upload to production (yay...).

We get to staging, I run my tests, all green, all working, so happy. I keep on working on other stuff, and the day that we were slated to upload to production, my coworkers find that throughout the development (which included a huge migration), code was removed which should not have. Team panics. Everyone is reviewing my commits (over a hundred commits) trying to see what we're missing that is required (especially legal requirements). Upload to production is delayed one day because of this. Ended up being one class missing, and a couple lines of code, which is my bad (but seriously, not bad considering I'm a Junior who was handed this project as his first task at his first job).

I swear to God, from here on out, one feature per branch and merge request. Never again shall I let this happen. I don't even know why it was allowed to happen, it breaks our branch policies. But ohel... I will now personally oppose crap like this too...

Now if you'll excuse me... I'm going to be highly unproductive and rest, because I might start balding otherwise after these weeks...

Sat here trying to decide and finalise my Dev process for Wordpress!

Roots.io clean, good code, deployment to staging and production through git

Vagrant then just push to live (which one?)

Docker then try and figure S*** out

Flywheel local!

Then decide where to deploy:

Digital Ocean or AWS Elastic with load balancers and S***!

Decisions!!

for the 3rd time ive tried introducing some version control on a project that really needs it because it has multiple people working on it.

And because the last time my efforts got shut down because in practice people thought it was too much of a hassle to develop locally rather than on the shared development server directly, I made a feature that would let people checkout branches on said server...

Apparently the action of; saving > committing > pushing to your feature branch > merge after aproval, is still too much for people to comprehend; "I think this is too convoluted can't we just keep pushing to the production server to check our work and then commit and push to the master branch"

So I just got pissed and said fuck it, no more git then, I'm not even going to put any effort into changing tooling here anymore, and this is a massive project where we have to manually remove code that isnt ready yet from the staging environment.

Are the people I'm working with just this stupid or am I really overengineering this solution because I think 4 people should not be working on the same file at the same time without any form of version control and just direct upload to FTP.

(and yes, I know I should leave this job already, but social anxiety of starting at a new company is a big obstacle for me)

I've having issues trying to form a proper branching strategy for my mean stack app deployment.

Heroku creates staging and prod branches for my web app so I'm a bit confused if I need my own staging branch?

Currently I have this: feature -> dev -> staging -> heroku staging (the staging branch seems useless)

Also, Heroku allows you to promote heroku staging to heroku prod, so there's no point in making master push to heroku prod.

I'm thinking of making my strategy to the following, but wasn't sure of any pitfalls or anything I'm overlooking long term.

feature -> dev -> master -> heroku staging -> manual promote to heroku prod.

Any suggestions?

Guessing my rant free streak is over. Trying to connect to a mongo atlas cluster. Just migrated from mlab as mongo Inc is discontinuing the heroku add on.
Migration went well. I can connect to atlas cluster via mongo shell.
Reactive mongo claims it supports dns seed list. I add mongodb+srv connection string. Doesn't work.
I go back to atlas and allow all ips access (migrating staging dB first to make sure all is well so I can whitelist all ips) - > send a request-> mongo error. No primary node is available.
Disconnect from my network, connect to another network, same thing. I push the connection string to my server, test using an ssl connection to make a request, still no primary node available. I am about to lose my mind.

We need to go live by this month 10.

Yep, infra is ready in production. You can push the events and see the results right away.

PM: Wow, great. Setup staging we need to test it.

Me: FML, staging machines are smaller, can't even start the program.

Develop a system with local env then when push to live staging.. It doest work.. Duhhh

We use Sequelize. This is how we do database structure changes:

- I create/change a model in Sequelize, and let it change my local database, then I do work on that
- I push the new code to a remote branch
- my boss/CTO/lead dev then manually creates/changes the relevant table(s) in our staging database
- I finally merge the branch I originally developed into the remote branch
- boss checks that everything is working
- at last, boss does the same process of modifying/creating tables in production database
- finally, staging code is merged into main

So right now:
- I'm changing a feature, forgot I was editing in the main branch
- go ahead and create a remote branch for it, pull locally, checkout local version of newly created branch
- try to run code
- oops, there's a missing column in one of my local database tables
- ask for boss for SQL script that will create the missing column and potentially add more data or whatever
- waiting for boss to respond

H-how can we improve this process? Boss has talked about us moving to use migrations but we never ended up doing it. I don't know much about migrations either. This is gonna suck so hard.