Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "release process"
-
*came in this morning to see this conversation in slack from the remote teams*
Dev: Hey guys, I'm trying to push to the develop branch, telling me its locked. Is there a new process?
Lead dev: Yes I locked it because the repo is now dead, the last release that went out is the last for this year and ever for this app. Were merging this app with another, starting from the last release's code. We'll all have to swap over to the new repo soon.
Dev: ... eh ok I didn't put anything in the last release branch as it wasn't urgent. Normally our process is anything in /develop goes out in the new year. I've been merging to /develop for the last few weeks ... is that code now gone?
*14 question mark emoji reactions*
Lead dev: Yes
*27 angry emoji reactions*
Engineering manager: WHAT? when was this decided? When was it communicated?
Lead dev: oh I assumed my product counterpart had been spreading the messages around, have they not?
Several teams: no, nope, first i'm hearing of it.
Lead dev: Ok, i'll ask them what happened. Be aware then that most of the stuff thats going into develop now, most likely won't be allowed in until March. They want to prioritise releasing this new merged app and don't want anything to impact it.
Dev: So wait, i'm working on stuff now. What do I do? Where do I base the branch? Where do I merge?
<no response>
*My team comes into the office*
Dev: eeehhh ... what does this mean for our past 4 weeks of work? and all the stuff needed to go out in January?
Me: not.a.fucking.clue16 -
I. FUCKING. HATE. MOBILE. DEVELOPMENT.
I already manage the data, devops, infra, and most of the backend dev.
We had a mobile guy. He was great. I never had to think about it and kept moving quickly on my work. #SpecializationOfLaborFTW
He left. Why? Because they wouldn't give him a small raise despite being one of the best mobile engineers in the firm. WTF.
I made the mistake of picking up just enough slack on this workflow in the interim such that I'm, apparently, the fucking god-damned release manager, fixer of pipelines, fixer of build configs, fixer of anything where someone just needs to RTFM for a half-hour to not fucking break things.
Now, 8 months later...and, apparently, Fortune 500 companies are too fucking god-damned cheap to pay for someone who actually knows WTF they're doing for a very reasonable thing to have at least one dedicated set of eyes for.
I never wanted to be a mobile dev.
I never will want to be a mobile dev.
And I certainly don't want to manage your HALF-FACE-FUCKED detached expo configs.
There's a reason I never intentionally involved myself in mobile. All the way down, it's just shitty cross-compilation, transpilation, dependency-hell, brittle-as-fuck build processes so we can foot-gun and mouth-gun react-native and expo and babel and whatever the fuck else cargo-culted horseshit into the wild.
And why? What's the actual fucking root cause? The biggest white elephant that ever fucking elephant-ed? It's because Apple and Google decided to never collaborate on a truly-native cross-platform SDK--where engineers could write native code that compiles to native binaries that's simply write-once, run-everywhere. They know they could have done that, and they didn't. So what'd they get back? Expo--a too-cleverly-designed backdoor/hack--more-or-less a way to circumvent the sane release process software has usually followed: code -> executable -> deploy. Or code -> deploy (for interpreted langs). Expo's like "keep your same executable, we're just gonna to do updates by injecting new code into it whenever we want". Didn't we learn anything with web? Shit gets messy real quick? Not to mention: HEY EXPO, WE WERE ALREADY BUILDING NATIVE APPS, YOU SHORT-SIGHTED FUCKS. THANKS FOR LURING OUR CTOs INTO FORCING EXPO DOWN OUR THROATS W/ THE IMPLICIT (BUT INCORRECT) TOO-GOOD-TO-BE-TRUE PROMISE THAT WE CAN HAVE WRITE-ONCE, RUN-ANYWHERE WITHOUT ANY BUY-IN OR COOPERATION FROM THE ACTUAL TARGET PLATFORMS.
And, we just, like, accept this? We all know it's garbage engineering. The principles we learned in the classroom aren't just academic abstractions--they actually yield real-world results--and eschewing them yields real-world failures. Expo is tightly-coupled to high-heaven, with leaky abstractions six-ways-to-christmas, chock-full of foot-guns, and fails the most basic test of quality: does it, "just work?"
Expo is fucking shameful and it should fucking die. Its promises are too bold, its land-mines too many, its future-proof-ness is alway, always, always questionable as fuck and a risk to every project that uses it.
You want a rant? This is my fucking venue, 'tis not? Well, then this is a piss and vinegar rant straight from my blood-red, beating fucking heart:
EXPO FUCKING SUCKS. AND IF YOU'RE A FAN, YOU FUCKING SUCK TOO.27 -
I've had many, but this is one of my favorite "OK, I'm getting fired for this" moments.
A new team in charge of source control and development standards came up with a 20 page work-instruction document for the new TFS source control structure.
The source control kingpin came from semi-large military contract company where taking a piss was probably outlined somewhere.
Maybe twice, I merged down from a release branch when I should have merged down from a dev branch, which "messed up" the flow of code that one team was working on.
Each time I was 'coached' and reminded on page 13, paragraph 5, sub-section C ... "When merging down from release, you must verify no other teams are working
on branches...blah blah blah..and if they have pending changes, use a shelfset and document the changes using Document A234-B..."
A fellow dev overheard the kingpin and the department manager in the breakroom saying if I messed up TFS one more time, I was gone.
Wasn't two days later I needed to merge up some new files to Main, and 'something' happened in TFS and a couple of files didn't get merged up. No errors, nothing.
Another team was waiting on me, so I simply added the files directly into Main. Unknown to me, the kingpin had a specific alert in TFS to notify him when someone added
files directly into Main, and I get a visit.
KP: "Did you add a couple of files directly into Main?"
Me:"Yes, I don't what happened, but the files never made it from my branch, to dev, to the review shelfset, and then to Main. I never got an error, but since
they were new files and adding a new feature, they never broke a build. Adding the files directly allowed the Web team to finish their project and deploy the
site this morning."
KP: "That is in direct violation of the standard. Didn't you read the documentation?"
Me: "Uh...well...um..yes, but that is an oddly specific case. I didn't think I hurt any.."
KP: "Ha ha...hurt? That's why we have standards. The document clearly states on page 18, paragraph 9, no files may ever be created in Main."
Me: "Really? I don't remember reading that."
<I navigate to the document, page 18, paragraph 9>
Me: "Um...no, it doesn't say that. The document only talks about merging process from a lower branch to Main."
KP: "Exactly. It is forbidden to create files directly in Main."
Me: "No, doesn't say that anywhere."
KP: "That is the spirit of the document. You violated the spirit of what we're trying to accomplish here."
Me: "You gotta be fracking kidding me."
KP grumbles something, goes back to his desk. Maybe a minute later he leaves the IS office, and the department manager leaves his office.
It was after 5:00PM, they never came back, so I headed home worried if I had a job in the morning.
I decided to come in a little early to snoop around, I knew where HR kept their terminated employee documents, and my badge wouldn't let me in the building.
Oh crap.
It was a shift change, so was able to walk in with the warehouse workers in another part of the building (many knew me, so nothing seemed that odd), and to my desk.
I tried to log into my computer...account locked. Oh crap..this was it. I'm done. I fill my computer backpack with as much personal items as I could, and started down the hallway when I meet one of our FS accountants.
L: "Hey, did your card let you in the building this morning? Mine didn't work. I had to walk around to the warehouse entrance and my computer account is locked. None of us can get into the system."
*whew!* is an understatement. Found out later the user account server crashed, which locked out everybody.
Never found out what kingpin and the dev manager left to talk about, but I at least still had a job.13 -
Trying to explain my job to friend who don't know computers.
Friend: So what do you do?
Me: Well they call me a "DevOps Engineer", but really I am just a Release or Automation Engineer.
Friend: What is that?
Me: Well I assist developers build and deploy their code as well as write code to automated the whole process and build the virtual servers.
Friend: So you like program?
Me: Kinda...
Friend: Dude can you write an app for me, got some ideas!
Me: (blinks) no.6 -
Never, ever, ever, release on a Friday. But.....
if you do.
Add this step as part of your production push process.2 -
TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.
I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.
FF to today:
- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"
And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.11 -
So yesterday I deployed a build on our release environment and i had added a new rest api end-point which I needed to test.. A heads up though, its written in java spring and the entire flow consisted of too many calls/returns from various other java & python services.. Also to make things worse, the entire deployment is a really cumbersome process as you need to copy the build from one box to another..
After like almost 4-5 hours of debugging, adding logs left right & center, crazy upload speeds (yaa this is sarcastic) and frustation at its peak, I found the issue..
There was an if condition that was checking for equality between an enum constant & an enum in a request aaaannnnnddd
*Drum roll
THE CONSTANT ENUM BELONGED TO THE WRONG PACKAGE HENCE ALWAYS EVALUATING TO FALSE... ALSO, BOTH THE ENUMS IN THE DIFFERENT PACKAGES ARE IDENTICAL... FUCCKKKKKKK MY LIFE
😑🔫rant i am done with life why you do this java someone kill me now no tags nope i am not time to die i am dead1 -
Recap: https://www.devrant.io/rants/878300
I was out Thursday at the Hospital. I'm what the doctors would call "Ill as fuck"
So, Friday I’m back in the office to the usual: "How was that appointment?"
I know people mean well when they ask this. So, I do the polite thing and tell them it went as well as it could.
Realistically it does't matter how well it went... They haven't cured Crohn's because I showed up to the appointment. They know I'm fucked already.
But, push it down, add it to the future aneurism.
I had to go through the usual resignation meetings with managers:
"We"re fucked now you're going"
"yep"
"we need to get a handle on how fucked"
"already done that for you, here"s a trello board, very fucked."
"we need to put a plan together to drop all the junior devs in the shit with the work you’ve been doing"
"You need about 4 devs, please refer to the previous trello board for your plan"
Meanwhile, me and Morpheus are in constant communication because all of this is like a Shakespearean comedy.
So, I overhear a conversation between a Junior Dev and the Solution Architect.
[SA] took over the project because he knows better than two tried and tested senior devs -_- (fuckwit).
JD: "It took me one and a half days to build it out"
SA: "Yeah, it must have taken me twice as long... It must be a problem with the project, you should just be able to check it out and run it."
JD: "I know, it has to be wrong"
All of this is about Morpheus' work of art, of an Ionic 3 hybrid app.
I fumed quietly at my desk because I've been ordered by the Stazi to be hands off.
Since Morpheus and me were pulled from the project [JD] and [JD2] were dropped into it to get it over the line.
It"s unfortunate and I was clear and honest with my advice to them: I personally would not take over the project because I"d be way out of my depth... Oh, and the App works, so uh, there's no work to do.
They have been constantly at our desks. Asking fuckdiculous questions about how to perform basic tasks. So they can get Morpheus" frigging masterpiece to the user.
It"s like watching that touch up of jesus that got borked by an amateur. Shit I have google, it's like watching this happen: http://ti.me/NnNSAb
[JD] came to me Friday evening.
"I can’t get this to build to iOS or install on [Test Analyst]'s phone."
Me: "No worries brother, where are you stuck right now?"
[JD] describes the first steps with clear indication he hasn't googled his problem.
Life lesson: http://lmgtfy.com/?q=lmgtfy
Que an hour of me showing [JD] how to build an Ion3 project for iOS. Fuck it, your man's in a bind and he"s asked politely for help. I can show him quicker than he can read 3 sets of docos.
I took him through 'ionic cordova build ios', the archive and release processes in XCode 9, then the apk bundling process for droid. Finally we have an MAM so the upload process for that too.
All the while cleaning up his AppIDs, Profiles, deployment attempts.
Damn they were a mess.
I did this with a smile on my face, not because I could say "I told you so"... But. because when any developer asks you how to do something. If you know how to do it, you should always be happy to learn them some new tricks!
Dude's alright, he's been dropped in the shit. Now I know how badly so I'll help him learn things that are useful to his role, but aren't project specific.
As a plausi-senior dev (I'll tell you about that later); it's my job to make sure my team have what they need to go home smiling!
I’m not a hateful fucker, the guy asked me an honest question so I am happy to give him the honest answer.
I took him through it a few times and explained a few best practices. Most were how to do his AppID and ProvProfile set up. Good lad, took it all on board.
However! In his frustration, he pointed the finger at Morpheus' "David" (ref: Michelangelo).
He miraculously morphed into a shiny colourful parrot and fed me SA's line:
"you should just be able to build from a clean clone"
My response was calm and clear:
"You can, it took me 20 minutes on Thursday evening. I was bored and curios, so I wanted to validate Morpheus' work. Here it is on my iOS device and my Android device. It would have taken me 5 if my laptop wasn’t so horrifically out of date."
I validated Morpheus' work so I have evidence, I trust that brilliant bastard.
I just need to be able to prove it's good.
[JD] took this on board.
Maybe listening to two tried and trusted senior devs is better than listening to a headstrong Solution Architect.
When JD left for the weekend I was working a late one (https://www.devrant.io/rants/874765).
His sign off was beautiful.
"I think I can happily admit defeat on this one, it can wait until Monday."
To which I replied: "no worries brother, if you need a hand give me a shout."
Rule 1: Don't be a cunt.
Rule 2: If someone needs help and you can give it: Give it!
Rule 3: Don't interrupt James' cigarette time.
Rule 4: goto Rule 3.rant day 3 jct resigns crohns resignation solution architect wk71 invisible illness fuckwit illness junior developer4 -
Ah finally, the moment when being a web developer is full of joy.
☑️ Server-side rendering
☑️ Inline critical css
☑️ Add progressive image loading
☑️ Minify everything
☑️ Automate release process in CI
☑️ Lint everything
Now that the strucutre is up, time to code the actual website. This is gonna be good!8 -
After 8 iTunes Testflight Beta approvals for my app ... better still, I got hte app approved for the App Store a week ago to "de-risk" our "final submission" ... That's 9 approvals for my app, and we're ready to submit version 1.0.0 and actually release on the store. We take last week approved app and "developer reject" if to make room for the final tweaked version (minor tweaks, minor bugfixes). Submit version 1.0.0., plenty of time before it needs to be released.
But, what's this? "Meta Data rejected" for v1.0.0 because some piece of shit at Apple wants to watch a video of the app working with our hardware. What about the previous 9 approvals with the demo account connected to the demo hardware?
So we send a video within 1 hour of their unexpected request about the very foundational fucntionality of our app. That was 24 hours ago and these fucking assholes haven't even responded, no sign of when they will trouble themselves to respond. Pure limbo.
All the work up to this point was to "de-risk" their infamously shitty review process and all of it was in vain because it's somehow brand new information that our app works with our hardware.
Holy fuck, what a bunch of power-tripping assholes. All I can do is pace around and review the previous 2 months in my head to figure out what I could have done better. But I could not possibly have expected that after all the Testflight Beta approvals and after the recent App Store approval, that they would suddenly doubt that our software actually works with our hardware!!!!!
FUCK YOU APPLE!!!! FUCK YOU WITH ALL MY HEART!!!!!!2 -
At a certain client, was asked to help them with an "intermediary" solution to stopgap a license renewal on their HR recruiting system.
This is something I was very familiar with, so no big. Did some requirements gathering, told them we could knock it out in 6 weeks.
We start the project, no problems, everything is fine until about 2.5 weeks in. At this point, someone demands that we engage with the testing team early. It grates a little as this client had the typical Indian outsourcing mega-corp pointey-clickey shit show "testing" (automation? Did you mean '10 additional testers?') you get at companies who put business people in charge of technology, but I couldn't really argue with it.
So we're progressing along and the project manager decides now is a great time to bugger the fuck off to India for 3 months, so she's totally gone. This is the point it goes off the rails. Without a PM to control the scope, the "lead tester," we'll call her Shrilldesi, proceeds to sit in a room and start trying to control the design of the system. Rather than testing anything in the specification, she just looked at the existing full HRIS recruiting system they were using and starts submitting bugs for missing features. The fuckwit serfs they'd assigned from HR to oversee this process just allowed it to happen totally losing focus on the fact this was an interim solution to hold them over for 6 months and avoid a contract renewal.
I get real passive aggressive at this point and refuse to deliver anything outside the original scope. We negotiate and end up with about 150% scope bloat and a now untenable timeline that we delivered about 2 weeks late, but in the end that absolute whore made my life a living hell for the duration of the project. She then got the recognition at the project release for her "excellent work," no mention of the people who actually did the work.
Tl;Dr people suck and if you value your sanity, you'll avoid companies that say things like, "we're not in the technology business" as an excuse to have shitty, ignorant staff.6 -
Let me paint you a picture.
It's the day after code freeze. Code has been branched. It's time once again to verify tickets and run smoke check so we can begin our 3 days of blitz testing before we deploy.
As a team we all have roles to play in this process. Yet, every stinking release it is like pulling teeth to get everyone to take the initiative and verify tickets and run smoke check. Our principled engineer even reached his limit this morning and blew up on everyone.
When you are being paid good money to do a job, you need be an adult, be responsible, step up and do your job!2 -
Joined a new company / team to work on an iOS app that has 2 different backend environments "Dev" and "Prod". Also being referred to in iOS speak as "Debug" and "Release".
Been trying to get accounts on these backends (no sign up in app, its controlled via another process). Eventually get access to "Dev" for one of the regions, so I load up "Debug" and its not working.
This is odd, so I open the Android app and load "Dev" and it works? I then Notice Android has "Dev", "QA", "Staging" and "Prod" for every region where as iOS only has 2 of these.
So I go back to iOS and find the file for the settings and it has iOS Debug assigned a variable for the backend Dev ... which is actually pointing to QA. Because they use QA to Debug and not Dev.
... confused? join the club3 -
One day after the release of the website of a medium sized travel company, I made a big mistake by accidentally taking it offline for 1 hour during peak usage (~150 simultaneous visitors).
Turns out deleting the wrong image transformation cache folder in production can hang up the PHP process for taking too much load on regenerating image transformations.
The designer of PHP probably took a big load too while creating the first draft.9 -
There was an issue whilst you were away, we had to make a small css change.. We pushed it into master but it said something about the branch being behind the tip by 50 commits or something. It's okay, we forced it up though and force pushed it to production as well but the site went down.. In the end we had to ftp it up manually but the customer is saying things that were there before now aren't there any more?
I thought you put this "release process" in so things like this wouldn't happen! I think we need to review it as it clearly isn't working.4 -
We have a badly out of shape but functional product , the result of a "if its not broke don't fix it" mentality. The only thing manangement cares is our next release and making meetings to plan other meetings...
Now comes the time of the security Audit (PCI)...
Manager : oh noooo the audit will fix this issue, quickkk fix it !
Us : welllll its a lengthy process but doable, we just gotta do a,b,c,d,e . Part a is essentially what we need the rest are refactoring bits of the system to support part a since the performance would be shit otherwise
Manager: can you do part a before the audit starts ?
Us: yep.
Manager: do it . Oh and pop those other issues on JIRA so we can track em
Audit completed....
Manager: so we got through ok?
Us : 👍 yep
Manager: okayy, take those other issues..... and stick em at the bottom of the back log...
Us : huh ? *suspicious faces*..... okay but performance is gonna be poor with the system as it is cuz of part A....
Manager: yeaaahhh * troll face* ....about that.... roll it back and stick that too at the bottom of the log. We got to focus our next release. Lemme schedule a meeting for that 😊
Us : faceplam4 -
When you're trying to publish your first Cordova app and the PlayStore release including signatures and stuff takes you 2.5 hours, while the AppStore release takes you 5 days (including getting a huge Mac on your desk, signing up a D.U.N.S. for your company, figuring out the signing/provisioning process and fixing CSS/JS exclusively for iOS).4
-
"The tool to push new releases to the data centre blocked us last night. Saying all the nodes are 'unhealthy', resolve the issue(s) first. But then the remote team said 'we have a way around that' so we managed to get it deployed in time. We need to document the process as there were many ... 'shady' processes and steps involved lol"
- Manager explaining how the first production release on our new team went last night
... he called it a success1 -
My current job at the release & deploy mgmt team:
Basically this is the "theoretically sound flow":
* devs shit code and build stuff => if all tests in pipeline are green, it's eligible for promotion
* devs fill in desired version number build inside an excel sheet, we take this version number and deploy said version into a higher environment
* we deploy all the thingies and we just do ONE spec run for the entire environment
* we validate, and then go home
In the real world however:
* devs build shit and the tests are failed/unstable ===> disable test in the pipeline
* devs write down a version umber but since they disabled the tests they realize it's not working because they forgot thing XYZ, and want us to deploy another version of said application after code-freeze deadline
* deployments fail because said developers don't know jack shit about flyway database migrations, they always fail, we have to point them out where they'd go wrong, we even gave them the tooling to use to check such schema's, but they never use it
* a deploy fails, we send feedback, they request a NEW version, with the same bug still in it, because working with git is waaaaay too progressive
* We enable all the tests again (we basically regenerate all the pipeline jobs) And it turns out some devs have manually modified the pipelines, causing the build/deploy process to fail. We urged Mgmt to seal off the jenkins for devs since we're dealing with this fucking nonsense the whole time, but noooooo , devs are "smart persons that are supposed to have sense of responsibility"...yeah FUCK THAT
* Even after new versions received after deadline, the application still ain't green... What happens is basically doing it all over again the next day...
This is basically what happens when you:=
* have nos tandards and rules inr egards to conventions
* have very poor solution-ed work flow processes that have "grown organically"
* have management that is way too permissive in allowing breaking stuff and pleasing other "team leader" asscracks...
* have a very bad user/rights mgmt on LDAP side (which unfortunately we cannot do anything about it, because that is in the ownership of some dinosaur fossil that strangely enough is alive and walks around in here... If you ask/propose solutions that person goes into sulking mode. He (correctly) fears his only reason for existence (LDAP) will be gone if someone dares to touch it...
This is a government agency mind you!
More and more thinking daily that i really don't want to go to office and make a ton of money.
So the only motivation right now is..the money, which i find abhorrent.
And also more stuff, but now that i am writing this down makes me really really sad. I don't want to feel sad, so i stop being sad and feel awesome instead.1 -
If you're close to getting the application ready for release date and they just change the business process 🙄1
-
Of course the shouting episodes all happened during the era I was doing WordPress dev.
So we were a team of consultants working on this elephant-traffic website. There were a couple of systems for managing content on a more modular level, the "best" being one dubbed MF, a spaghettified monstrosity that the 2 people who joined before me had developed.
We were about to launch that shit into production, so I was watching their AWS account, being the only dev who had operational experience (and not afraid to wipe out that macos piece of shit and dev on a real os).
Anyhow, we enable the thing, and the average number of queries per page load instantly jumps from ~30 (even vanilla WP is horrible) to 1000+. Instances are overloaded and the ASG group goes up from 4 to 22. That just moves the problem elsewhere as now the database server is overwhelmed.
Me: we have to enable database caching for this thing *NOW*
Shitty authors of the monstrosity (SAM): no, our code cannot be responsible for that, it's the platform that can't handle the transition.
Me: we literally flipped a single switch here and look at the jump in all these graphs.
SAM: nono, it's fine, just add more instances
Me: ARE YOU FUCKIN SERIOUS?
Me: - goes and enables database caching without any approvals to do so, explaining to mgmt. that failure to do so would impair business revenue due to huge loading times, so they have to live with some data staleness -
SAM: Noooo, we'll show you it's not our code.
SAM: - pushes a new release of the monstrosity that makes DB queries go above 2k / page load -
...
Tho on the bright side, from that point on I focused exclusively on performance, was building a nice fragment caching framework which made the site fly regardless of what shitty code was powering it, tuned the stack to no end and learned a ton of stuff in the process which allowed me to graduate from the tar pit of WP development.5 -
TL;DR: I hate how management doesn't listen to devs (even Dev managers).
We need to sort out our release process where I'm at. It takes a Dev about 2 solid days to complete and it's hideously involved and ripe for human error. They're completely out of action until it's done and it happens once a week!
It's stopping us releasing business critical bug fixes and features that need to go out. Instead the work just sits in develop for days doing fuck all.
Can't be agile if it takes so long to deliver value 🙃
Plus makes any fuck ups by our department look worse as it takes an age until it's fixed which reduces their collective trust in us and our opinions.
Making any improvements we want to make harder todo as they're harder to convince 🙃
Has anyone had any success getting automated releases?
How did you convince management to prioritise it?
I need to convince someone who has some influence in my company and ask how they got that influence7 -
Currently working on app that is about 10 years old at work. Here’s how today has gone:
Can’t run application locally because the process management engine doesn’t allow access locally, can’t access in development because process management engine doesn’t work here either, can run app in test but waiting on special server access to get the logs.
Make the request to security to access the server - they decline it telling me that the form I submitted is outdated and to submit a new one. Requires three approvals, am still waiting on them.
Every time I make a change and want to test, I have to commit the changes, wait for them to build. Release the changes, build the release project and then deploy it in bamboo.
I can’t wait for my new job to start.1 -
You know what's fun? When your client insists you use an agile process with a delivery at the end of each sprint, then proceeds to bitch at each release at the features that weren't implemented yet. The thing isn't even slated to be done until 4Q 2018 and is on schedule/early. Glad I am not on that team . . . yet.
-
This is long rant/story:
My manager conducts sync-up meetings regularly. The idea is to sync up all developers on current state of work. He does’t conduct stand-ups. He doesn't have time for it. He rather discusses on individual basis if we are blocked. The rule of the sync-up meeting is NOT to discuss any blockers or problems but simply explain each other what we are doing and how we plan next.
Sometime ago, the manager brought up and explained a new way of working in the sync-up meeting. At this point, a new developer in the team was absent due to sickness.
Today, there was a sync-up meeting and the manager started to question the new member about the newly introduced way of working. He was unaware of it and the manager never communicated this important information via email or any mode of communication available.
So, the conversation goes on as follows:
"Manager": — "Why didn’t you complete your task as per the new way of working?"
"Employee": — "Well, I've no idea. Am I supposed to do? I’ve been working as usual like any other"
"Manager": — "We have a new process and you have failed to follow it, so we’re late in delivering your work"
"Employee": — "I’ve already finished my work on time. I've raised a pull-request this morning"
"Manager": — "It doesn’t matter, it is not merged to main branch and so we can’t include your work in the release"
"Employee": — "I’ve no idea about the new process"
"Manager": — "Haven’t you asked around about what happened from previous meeting"
"Employee": — "Yes, I have. I was told which tasks were handled, but nothing about a new process"
"Manager": — "Aren’t you interested to learn it?"
"Employee": — "Why won’t I be interested? I was on a sick leave and I have no clue what happened here"
"Manager": — "What’s happened is past now, let’s not focus on it"
"Employee": — <Dumbfounded>
The Employee felt ashamed in front of everyone. He did his job but it didn’t pay off.
…. After an hour … the Employee had a talk with the Manager
"Employee": — "You shouldn’t have pointed me out in front of everyone. It made me feel real bad. You should have emailed this information if its important for the team."
"Manager": — "I have no idea what you’re talking about. When did I say so? I think you’ve a bright future in the team. You should be focusing on doing better things."
Employee goes back to work. A minute later, the Manager sends a PowerPoint screenshot of the process in the group chat.
**The Process**
It's about delivering release packages based on priorities defined by client. Each release package is a set of work items or requirements. Individual developers are assigned to work items. They are expected to deliver on planned delivery timelines in order to consider a work item into a release package.1 -
Just got offered a awesome internal position. Asked what the interview process was and he said, "I've already seen you present and I've looked at your code. You've interviewed."
Now, if I can get get my current area to release me. 😑 -
PM tells me to merge (large feature) work that's heavily under WIP.
In that is a performance optimisation he instructed (with an aggressive DM) me to stop looking at even though it's a concern for larger clients that I had to fix before as it's "unnecessary" - thought whatever I'll leave the code as is then
I tell him him the PR is not ready yet, there is still a lot of clean up to and tests to write
Just do it
A ~week later "wow you write really selfish code like look at this"
Shows a wrapper class from the optimisation with 2 properties and getters and setters (and override some of super's properties). I explain to him why it's there, "that should have been a comment". I tell him I write detailed comments as part of my refinment process which he wanted me to stop.
This is after he tried to merge a release branch into main while sneaking in some "corrections" and I pointed out it breaks Dev.1 -
Was very sick today.
Hopped over to work virtually so I can help with an issue holding up prod release.
Felt pretty awesome about the whole deal.
Than realized three things:
1- this was a bad example to junior devs.
2- stole learning experience from other devs
3- I am leaving this company. I should have allowed the weaning process to start2 -
Man I am tired of my company's dogshit software release process.
We have to commit to fucking estimates for 6 months (2 quarters), SQA shadowing dev by 2 weeks, and freaking estimates and work done at the end are not even close. And then we call it a minor release. These shitty estimates are based on requirements that basically say "we want feature x, plz make it work". It's some fucked up agilefall garbage that does not work for shit.
We rush like motherfuckers during the final weeks because estimates are bullshit but we are still expected to be done with every story points which somehow are days instead of other better metrics.
I swear this fucking bullshit has been designed by the board so they could plan their money entries based on the software release.
The only reason this company actually still holds itself up is because the engineers are good at their job.
Go fuck yourself high management. -
I have started a new journey on a company on Jabuary 25. I put a lot of effort but apparently the client told my employer I took too many time in my onboarding process (they expected me to be ready in two weeks or less) and they deactivated my slack account (this was on monday, because although I had holidays I turn on my machine in order to advance). The client said this on friday and I got awared on monday. I feel frustrated... Because I put a lot of effort resuming the documentation and even my team mates said it was unfair; some of them took longer than two weeks and they havent make a PR.
So it seemed to me strange as I said... Some of the conclusions we arrived were: We should ask for credentials 1 week before. The other thing was: The guy who technically interviewed me was really important in the project and he has a cool posibility on Barcelona (spain). We assumed that the client feel angry or sad about this and because they want to keep still the relation but want other provider to supply that dev guy, they arose with silly and stupid time requirements. I did all I could taking into account they didnt give me all the credentials at the same time; the first one came one week after.
Soooo here I am... Enjoying a good bench time and learning angular !!!!... sincerely... I wanted to release some shots to the air jaja -
In my previous rant:
Last week I resigned, in the meantime they've completely reworked the git flow process and made PR's optional, among other stuff.
Today: "Architects" ask that we stop creating tags. We're replacing release tags with release branches.
I feel dirty only for imagining having to do a "git checkout -b "v1.2.3".
Good times :)4 -
I can now leave freely without any regrets!
The slight misgivings I had about leaving this place over the toys they provide, is now gone because I re-realized that while this place adopts new tech, it doesn't adapt to it. So they have shiny tools but the people and processes won't change.
It seems to me that due to pressure to deliver, there is little thought/analysis behind any tech change.
They don't plan to change their wretched delivery pipelines. Everything will be same but on git. So no velocity gains, and same bureaucratic review request process. Such a waste. This attitude applies to their other tools too. They are using a unit test library to write tests that don't use mock. They are using modern languages but without modern idioms. It's like writing C code in C++. And of course theoretically we are agile but actually we're just a waterfall team with managers on our ass everyday and tighter release schedules.
Reminds me of @boombodies recent posts and discussion about business spaghetti reflecting in code.
There are possibly multiple reasons for these problems but I think a large part of it is a lack of empathy/mutual respect. Everyone's too insecure, noone cares for anyone but themselves and people just try to outwit each other. -
I am amazed at human stupidity.
I always enjoyed the idea of DevOps: to use virtual machines and constant integration in order to avoid errors and free the developers of hard-to-setup environments and somehow-it-works compilations.
I am amazed how [company I used to work for] managed to turn this into a nightmare.
Just imagine: silent forests, the smell of flowers, no developer trust to the point your devs can’t either make docker environments cause reasons nor they can access your actual machines programmatically because they are filthy peasants, forcing them to do everything manually: every deployment will be a frustrating editing process which takes up to an hour, but here lies the trick... it will still have continuous integration... or better: every feature will be deployed as if it was a release.
The true peak of illumination:
Turning a tool into a disease.
Take a sip of tea, manager... you deserve it.
Just thought about this job because I keep being tempted to just start my own company. The more I think about it, the less being employed makes sense, given my end goal.2 -
So as expected, due to the rush of the submission on Friday, the app was rejected.
I'm fairly certain they never got past the first screen or two.
We have some things to fix, and some things to tackle properly now, which is quite nice, however the current main issue numero uno is that an Apple developer account can take up to 10 days to be created, and Go Live is next Monday.
I wonder who will get the blame for not taking on the "Investigate the iTunes release process" ticket that was in Jira, assigned to someone for ~4 months. -
/** Null until this web socket is connected. Used for writes, pings, and close timeouts. */
private ScheduledExecutorService executor;
Dear boys and girls.
If you ever do this again and release this as a public library (even better - an official client of your solution, e.g. kuber-fucking-netes), I will get my way into dR's gateway servers, trace down your IP in nginx's logs, find your location, probably use some means to get your first and last name (you prolly have a domain registered under your IP anyways...), buy a ticket to your town, get to your home and wait for night to fall. Once it's dark and you're asleep, I'll make sure to leave a real nice, warm and extraordinarily smelly turd on your doorstep (I'll also make sure the process of manufacturing that gem is as noisy as it gets - you just have to bend the right way, and....).
Gents. If you really, REALLY want to make writes asynchronous, at least provide a way to either get a notification once the write is synchronized, or allow the user to handle the threads/executors himself!
https://youtube.com/watch/...5 -
Wow WTF!
So for a new client, they have their domain on a registrar that has the most ugliest and confusing UI ever.
So I decided to transfer the domain to somewhere better.
Guess what, it takes 5 days for them to release the domain. The site would be down and I won't be able to proceed with my work until transfer is complete.
In hopes to speed up the process, I tried to create a ticket. There is no ticket system and their only available contact email listed is sales@shittiestdomainregistarever.com
I mailed them yesterday evening hoping for a reply.
Few hrs ago, I received a bunch of automated email on some ticket I never created.
The biggest WTF is that the To: on that email is some other customer's gmail address and I am CC'd along with a bunch of other customers gmail and hotmail addresses.
Seriously, WTF is this?! I'm glad I took the decision to move from them19 -
I just realized something. So my company's whole release process and code management now run on mainstream tech products: Atlassian, Jetbrains, IBM and not in house/vendor crap1
-
story of a release
v2.1.0 major changes went live : new features, bug fixes, optimisations. also included releases for 2 associated libraries
release process tasks:
- do code
- update test cases
- test sample app
- test on another sample app
- get code reviewed and approved by senior ( who takes his own sweet time to review and never approves on first try)
- get code reviewed again
- merge to develop after 20 mins( coz CICD pipeline won't finish and allow merging before that)
- merge to master after 20 mins( coz CICD again)
- realise that you forgot to update dates in markdown files as you thought the release will be on 10th sept and release is happennig on 12th sept coz of sweet senior's code fucking/reviewing time
- again raise a branch to develop
- again get it a review approval by sr (who hopefully gives a merge approval in less time now)
- again get it merged to develop after waiting for 20 mins
- again get it merged to master after waiting for 20 mins
- create a clean build aar file
- publish to sonatype staging
- publish to sonatype release
- wait for 30 mins to show while having your brain fucked with tension
- create a release doc with all the changes
- update the documentation on a wyswig based crappy docs website
- send a message to slack channels
- done
===========
why am i telling you this? coz i just found a bug in a code that i shipped in that release which still got in after all the above shitty processes. its a change of a 3 lines of code, but i will need to do all the steps again. even though i am going through the same shitty steps for another library version upgrade that depends on this library 😭😭
AND I AM THE ONE WHO CAUGHT IT. it went unnoticed because both of those shitty samples did not tested this case. now i can keep mum about it and release another buggy build that depends on it and let the chaos do its work, or i can get the blame and ship a rectification asap. i won't get any reward or good impression for the 2nd, and a time bomb like situation will get created if i go with 1st :/
FML :/6 -
Hello and welcome to COMPANY! Where our release process is more complicated than writing the goddamned code. Enjoy using our shitty undocumented, proprietary tools to create change requests and then thrill as it takes days to do anything!
Seriously, fuck this stupid shit. Who's grand idea was this. I am a developer, not a paper pusher.3 -
Ever suggest improvements and get shot down at every turn? I was discussing automating our release process today and suggesting that instead of having to do everything manually and babysit the build, we should let Jenkins deal with releasing and the attitude was that we shouldn't even try because we'd spend more time maintaining the automation and wouldn't gain anything. Obviously I disagree, but it seems like I'm always coming up against shit like this.
Our requirements gathering is another point of contention; I think we could be way better at it if we invested more time talking to customers before a project starts but the attitude is to get straight into development and deal with that later.
I don't know why I even bother sometimes...4 -
In last episode of "How SystemD screwed me over", we talked about Systemd's PrivateTMP and how it stopped me from generating SSL certificates.
In today's episode - SystemD vs CGroups!
Mister Pottering and his team apparently felt that CGroups are underused (As they can be quite difficult to set up), and so decided to integrate them into SystemD by default. As well as to provide a friendlier interface to control their values.
One can read about these interactions in the manual page "systemd.resource-control"
All is cool so far. So what happened to me today?
Imagine you did a major system release upgrade of a production server, previously tested on a standalone server. This upgrade doesn't only upgrade the distribution however, it also includes the switch from SysVInit to SystemD. Still, everything went smooth before, nothing to worry now then, right? Wrong.
The test server was never properly stress-tested. This would prove to be an issue.
When the upgrade finishes, it is 4 AM. I am happy to go to bed at last. At 6 AM, however, I am woken up again as the server's webservices are unavailable, and the machine is under 100% CPU load. Weird, I check htop and see that Apache now eats up all 32 virtual cores. So I restart it, casting it off to some weird bug or something as the load returns to normal.
2 hours later, however, the same situation occurs. This time, I scour all the logs I can, and find something weird - Many mentions that Apache couldn't create a worker thread? That's weird.
Several hours of research and tinkering later, I found out the following:
1 - By default, all processes of a system that runs SystemD are part of several CGroups. One of these CGroups is the PID CGroup, meant to stop a runaway process from exhausting all PIDs/TIDs of a system.
This limit is, by default, set to a certain amount of the total available PIDs. If a process exhausts this limit, it can no longer perform operations like fork().
So now, I know the how and why, but how should I solve this? The sanest option would be to get a rough estimate of just how many threads the Apache webserver might need. This option, though, is harder, than apparent. I cannot just take the MaxRequestsWorkers number... The instance has roughly double the amount of threads already. The cause being, as I found out, the HTTP/2 module, which spawns additional threads that do not count towards this limit. So I have no idea what limit to set.
Or I could... Disable the limit for just the webserver via the TasksAccounting switch. I thought this would work. And it did seem to... Until I ran out of TIDs again - Although systemctl status apache2.service no longer reported the number of tasks or a task limit of the process, the PID CGroup stayed set to the previous limit. Later I found out that I can only really disable the Task Accounting for all the units of a given slice and its parents.
This, though, systemctl somewhat didn't make apparent (And I skimmed the manual, that part was my fault)
So... The only remaining option I had was to... Just set the limit to infinite. And that worked, at last.
It took me several hours to debug this issue. And I once again feel like uninstalling systemd again, in favor of sysvinit.
What did I learn? RTFM, carefully, everything is important, it is not enough to read *half* the paragraph of a given configuration option...
Oh, and apache + http/2 = huge TID sink. -
Our most recent development process:
1. Implement feature
2. Create task
3. Release feature
4. Review feature
4.1 Possibly reimplement
5. Add tests1 -
is it necessary to have cherry picking a part of git branching/release process?
we have 3 branches : develop, release and master.
currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.
so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :
1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.
2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x
3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release
4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.
so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.
for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.
what do you folks suggest?9 -
TLDR;
Side project update.
Made simple nlp library in python and published it’s first version to open source.
Now I can feed it with parsed pdf text.
See rant https://devrant.com/rants/2192388/...
Why ?
Cause during reading book about nltk I couldn’t find simple extendible way to provide support for polish language and I wanted to abstract stemming, word normalization, tokenizer etc. so I can provide ex. different conditions for separate text files and don’t write much code what is an asset when you work solo.
It’s about 12GB of pdf public accessible law data I am trying to handle ( at first ) which is about 35000 files from last 90 years.
So far I automated downloading web pages and pdf documents from them. Extracting data from web pages and saving it to database. Extracting text from pdf files. I have about 5-6 projects to do all of it above maybe at the end I will put it to some workflow manager like Luigi or just run it by cronjob.
First thing for website version 1.0 part is find correlation between all documents inside law text using nlp library by building custom conditions. Then just generate directory structure and html files with links between documents.
Website version 2.0 is already in my mind but it will be creepy to make it and will take at least 1-2 months and I want to publish fast.
I have some pdfs with only images instead of text and tesseract worked quite good with them so maybe I will try to process them when everything go live.
Learned a lot about pdf as now I know that font in pdf is not always providing unicode characters ( stupid form of obfuscation) so when you extract text you need to build glyph vector to text map for every font.
Pdf is full vector representation - just like svg - what is logic if you think a bit and know that some printers are running using postscript.
Let’s hope next update will be about flutter mobile app which started all of shit above. It’s almost ready ( except getting data from api I am trying to do and logo for release version ). It’s last piece of puzzle.3 -
Our owner's other company sells products online (or has the ability to anyways). Their current site is 7+ years old WordPress/Woocommerce and is seriously outdated because the site breaks if you update anything so we've been told to make a new site (finally). They also said they were going to release a whole new line up of products. So the first thing I tried to do was get them to nail down their product line and how shipping was going to be configured. I was told to just use the shipping from the previous site.
Turns out those shipping rates don't use any sort of math or automation at all, there is literally a manually set shipping value for every single product for every single shipping location (30*60) and even values for different quantities. And there's no way to export these rates into a readable table because the plugins they use shove all the data into the postmeta table, I'm forced to go through and put the data into a spreadsheet so that I can attempt to organize it and hopefully find someone way to automate it. Owner claims at one point that he has a similar spreadsheet that's more up to date but for some reason refuses to send it over or put me in touch with the right people in the shipping department.
I've gone through the shipping rates with the old products and the new products and organized them as best I can and each time I've gotten done and shown them the spreadsheet with their products and shipping, they add or change something which requires me to basically wipe the slate clean and start over eating another 50 or so hours of my time, which with everything else really means another month+ to find time to work on it between other projects.
After about a year they finished their products and I finally finished the planning and got approval to build it out for the site. Small victory!!
After about 60 hours plugging these values into the database (only about 1/3 done) I get an email from their head of shipping who tells me the values in my spreadsheet are "terribly inaccurate, in some areas by $100+" and that the data should not be used anywhere.
So after something like a year and a half and 200+ hours of work, the data I've been using to plan all this isn't even accurate. I'm trying not to go crazy here but this kind of shit is unacceptable. When we're done with this I'm going to send the owner an invoice to show him how much money he wasted on this because nothing was planned and he just wanted it built. There's a fucking process for a reason, when you don't follow the process you fuck everything up. If a client had pulled this shit and turned their simple site into this much work they would have been dropped. I get constant emails asking when the new site will be done and every time my answer is "I'm still waiting for x items that I asked for last time you asked where we were." He gets a couple things on the list and sends them back and then goes unresponsive for weeks at a time.
Management has been telling me that I seem more stressed lately but only one of them understands what's going on here when I explain it. The rest say stupid shit like "why don't you automate it" or "make an intern do it." You won't let me hire an intern and even if I did, I'm not sure I could explain how the shipping works now to even trust someone else to do it. I'm hoping when the shipping guy gives me the new sheet that maybe there's some easier solution here because I'm ready to start shooting people.2 -
Extremely frustrated with the release process and versioning system at my current company. Don't know if this is same everywhere or the half ass release managers can't think of a better way here.
Basically for any client raised issue that can't wait for next release are built as a hotfix. However hotfixes are never bundled togather or shiped to other clients. This is causing a vicious chain, two clients raise two separate issues on same version. Instead of fixing them as single hotfix (however minor the issues) we create two hotfix versions for each with only their issue. A week later same clients come back with the issue the other raised. Once again instead of bundling what is now effectively same code we build hotfixes on top of the clients respective branches. We now have two branches to maintain with same codebase. No matter how serious issue, the hotfix is never made generally available and always created on client's specific hotfix version.
Now that was an example for only two clients, in reality we have released five patch versions of a product in last 2 years. Each product version contains about a dozen artifacts (webapps, thick clients, etc) with its own version. Each product version being shipped to various clients. Clients being big banks never take a patch of product even if it fixes their issues and continues requesting hotfix. We continue building hotfixes on client branch and creat ever increasing tech debt. There is never a chance to clean up or new development. Just keep doing hotfix after hotfix of same things.
To top if all off, old branches are still in svn while new in git. Old branches still compile with ant new with maven. Old still build with java 5,6,7 while current with 8. Old still build from old jenkins serve pipelines while new has different build server. Old branches had hardcoded integration db details which no longer exists so if tou forget to change before releasing it doesn't work.
Please tell me this is not normal and that there are better ways to do this? Apologies I think I rambled on for too long 😅5 -
Oh here's a good one. When the managers realised one of our apps is a giant hunk of crap that wasnt thought through at all and was lazily thrown together, and their solution is "meh let's just rewrite it in Swift on our new platform. And those other guys can maintain the old one and continue to do hotfixes for it until we are done".
I've been telling them for the past year that its the worst codebase I have ever seen and the lack of tests is disgusting and not something we should dare to release to paying customers (especially when those customers work in healthcare!!!). The best part was when one of them promised we would all be working on the new shiny platform by Christmas. That was last year. And I'm currently the poor bugger doing the legacy maintenance and in the process of trying to get moved to a new project. So much for managers promises amirite... -
Not a productive day. I wanted to restore part of database from test server but downloading data using reat api was getting timeouts.
I made simple app that dumps data and I launched process in screen and started watching Dragon ball
I like those old first series with young Songo looking for his grandpa.
After about 2 hours and partial backup still not finished I started to cut crap data from backup script will finish it tomorrow.
Looks like my ux is still ok and views got almost all approved.
Need to fix some shit on backend but I need those backups to work for more complicated customers.
Luckily frontend developer is back so he will handle visual parts.
Maybe we will release new features on the beginning of February.3 -
When your companies release/building process is more complicated than writing and architecting the fucking project.
Fuck my life. -
Tried to deploy a release ... pasted the git tag after copying it from a Jenkins build. We’ve done this a thousand times, BAU....
The deployment process tries to `git ls-remote 'git@git-repo.com:org/repo.git' '5.1.0*'` and complains it can’t find the tag in the remote.
Three hours later, 20 grey hairs the richer, I copy the build log into Slack to get some validation from others that I’m not crazy.
`git ls-remote 'git@git-repo.com:org/repo.git' '<200b><200b>5.1.0*'`
Faaaarrrrrrrrrrrrrrrr .... -
The fucking release process. We release weekly which is stressful for both Devs and QA’s. Everything should be committed/promoted in our DVCS by Thursday and should be verified beforehand. The problem is, QA’s doesn’t take development builds, they only want to take whats fucking next in release. In other words WE. FUCKING. RELEASE. UNTESTED. SOFTWARE.
Man, BA’s have it easy on our team.1 -
What my ADHD brain looks like to an outsider:
My media player doesn't support ordered chapters, so now I have FreshRSS running on my VPS.
The actual mental process:
> MPC-BE doesn't support ordered chapters with the built-in filters
> I should install the third-party LAV Filters
> Not available on Scoop and I'm never touching Chocolatey again
> I wish I had Linux on this PC instead of Windows, so I could have a proper package manager to handle updates, but I digress
> Sure would be nice if I could find a way to know when this updates.
> Actually, tracking versions for multiple GitHub repos would be really nice.
> I would just subscribe but my email inbox is a mess already and I'd probably fail to see the emails
> GitHub Release pages have their own Atom feeds!
> I don't currently use any feed readers
> Maybe I should self-host a feed reader
> Set up FreshRSS Docker container on my server
> Actually installed the LAV Filters to solve the original problem.7 -
3 weeks back took a bug..
**long rant**
Looked into it and found that it is exist in older version(say V1) as well.
Sent mail to client stating i can fix this in current version (say V2). Since V1 is already released and our current code stream is V2 and so if we fix in V2 , the code will not reach V1 code base.
**explained to client**
Client : I mean if you fix why it won't work in older release.
Me: Explains how code streams will work.
Client : Okay.. but it will support the functionality in V1 , right ?
Me: (*internally* are fucking kidding me? It won't work dumb ass.) No. It won't work in older versions. I am fixing it in V2.
client: okay.. Let's proceed.
Me: Done code changes. Send code to review. (we have to send review to upper level manager).
Manager1 : I didn't liked this part. can you change this ?
Me : sure. Done.
Manager1 : Now i liked it. Sent review to Manager2.
Me: why the fuck ? Are you not sure about my changes are good?
Manager 2: I liked it, but need some log changes.
Me: Fuckkkk...... Let me change this.. Done. Now can I promote those changes?
Manager2: No we need to send review to client manager as well.
Me: Goddammit.. Okay.. sent review.
*After a fucking week..*
Client Manager : Looks good. Push the code.
Me: Finally..
(This process took 18 days which would have been completed in 3 days if there is only one peer review)
Now the other guy from client whose tracking the bugs reported why it took so long to fix it.
I think my client manager is over paid and can't even know how his company code stream works. Fuck you . why client has these lazy ass old fucking "I don't look into my email" type people. God I hate these "I am in rich country" people.2 -
Just joined a new company and can only describe the merge process as madness.....is it or am I the one that is mad?!
They have the following branches:
UAT#_Development branch
UAT#_Branch (this kicks of a build to a machine named UAT#)
Each developer has a branch with the # being a number 1 to 6 except 5 which has been reserved for UAT_Testing branch.
They are working on a massive monolith (73 projects), it has direct references to projects with no nuget packages. To build the solution requires building other solutions in a particular order, in short a total fucking mess.
Developer workflow:
Branch from master with a feature or hotfix branch
Make commits to said branch and test manually as there are no automated tests
Push the commits to their UAT#_Development branch, this branch isn't recreated each time and may have differences to all the other UAT#_Development branches.
Once happy create a pull request to merge from UAT#_Development to UAT#_Branch you can approve your own pull request, this kicks off a build and pushes it to a server that is named UAT#.
Developer reviews changes on the UAT# server.
QA team create a UAT/year/month/day branch. Then tell developers to merge their UAT#_branch branches in to the previously created branch, this has to be done in order and that is done through a flurry of emails.
Once all merges are in it then gets pushed to a UAT_Testing branch which kicks off a build, again not a single automated test, and is manually tested by the QA team. If happy they create a release branch named Release/year/month/day and push the changes into it.
A pull request from the release branch is then made to pre-live environment where upon merge a build is kicked off. If that passes testing then a pull request to live is created and the code goes out into production.
Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh it's a total mess. I knew when I took on this job it would be a challenge but nothing has prepped me for the scale of the challenge!! My last place it was trunk based development, commit straight to master, build kicks off with automated testing and that just gets pushed through each of the environments, so easy, so simple!
They tell me this all came about because they previously used EntityFramework EDMX models for the database and it caused merge hell.9 -
Any of you are annoyed by your non-technical manager work practices?
Every release I feel like our manager's goal is to have our planning and results look good in front of higher management, no matter if it is true or not.
Oh this big task could not be done because we had to plan 4 months in advance with no info and poorly done requirements? Well let's just push it to the next release we can't have unfinished tasks logged in.
Oh we don't have time to work on tech debt and refactoring, there are too many features and bugfixes to do. Well maybe that is why there are so many bugs, eh?
Oh your automated test results need to all look perfect, does not matter if your test are even good or actually doing anything in the first place, as long as it passes.
Also, I was promised agile and got a waterfall-like bullshit process instead that barely works.
Anyways just morning rambling.1 -
TLDR, need suggestions for a small team, ALM, or at least Requirements, Issue and test case tracking.
Okay my team needs some advice.
Soo the powers at be a year ago or so decided to move our requirement tracking process, test case and issue tracking from word, excel and Visio. To an ALM.. they choice Siemens Polarion for whatever reason assuming because of team center some divisions use it..
Ohhh and by the way we’ve been all engineering shit perfectly fine with the process we had with word, excel and Visio.. it wasn’t any extra work, because we needed to make those documents regardless, and it’s far easier to write the shit in the raw format than fuck around with the Mouse and all the config fields on some web app.
ANYWAY before anyone asks or suggests a process to match the tool, here’s some back ground info. We are a team of about 10-15. Split between mech, elec, and software with more on mech or elec side.
But regardless, for each project there is only 1 engineer of each concentration working on the project. So one mech, one elec and one software per project/product. Which doesn’t seem like a lot but it works out perfectly actually. (Although that might be a surprise for the most of you)..
ANYWAY... it’s kinda self managed, we have a manger that that directs the project and what features when, during development and pre release.
The issue is we hired a guy for requirements/ Polarion secretary (DevOps) claims to be the expert.. Polarion is taking too long too slow and too much config....
We want to switch, but don’t know what to. We don’t wanna create more work for us. We do peer reviews across the entire team. I think we are Sudo agile /scrum but not structured.
I like jira but it’s not great for true requirements... we get PDFs from oems and converting to word for any ALM sucks.. we use helix QAC for Misra compliance so part of me wants to use helix ALM... Polarion does not support us unless we pay thousands for “support package” I just don’t see the value added. Especially when our “DevOps” secretary is sub par.. plus I don’t believe in DevOps.. no value added for someone who can’t engineer only sudo direct. Hell we almost wanna use our interns for requirements tracking/ record keeping. We as the engineers know what todo and have been doing shit the old way for decades without issues...
Need suggestions for small team per project.. 1softwar 1elec 1mech... but large team over all across many projects.
Sorry for the long rant.. at the bar .. kinda drunk ranting tbh but do need opinions... -
i am feeling angry and frustrated. not sure if it's a person ,or codebase or this bloody job. i have been into the company for 8 months and i feel like someone taking a lot of load while not getting enough team support to do it or any appreciation if i do it right.
i am not a senior by designation, but i do think my manager and my seniors have got their work easy when they see my work . like for eg, if on first release, they told me that i have to update unit tests and documentation, then on every subsequent release i did them by default and mentioning that with a small tick .
but they sure as hell don't make my work easy for me. their codebase is shitty and they don't give me KT, rather expect me to read everything on my own, understand on my own and then do everything on my own, then raise a pr , then merge that pr (once reviewed) , then create a release, then update the docs and finally publish the release and send the notification to the team
well fine, as a beginner dev, i think that's a good exercise, but if not in the coding step, their intervention would be needed in other steps like reviewing merging and releasing. but for those steps they again cause unnecessary delay. my senior is so shitty guy, he will just reply to any of my message after 2-3 hours
and his pr review process is also frustrating. he will keep me on call while reviewing each and every file of my pr and then suggest changes. that's good i guess, but why tf do you need to suggest something every fucking time? if i am doing such a shitty coding that you want me to redo some approach that i thought was correct , why don't you intervene beforehand? when i was messaging you for advice and when you ignored me for 3 hours? another eg : check my comment on root's rant https://devrant.com/rants/5845126/ (am talking about my tl there but he's also similar)
the tasks they give are also very frustrating. i am an android dev by profession, my previous company was a b2c edtech app that used kotlin, java11, a proper hierarchy and other latest Android advancements.
this company's main Android product is a java sdk that other android apps uses. the java code is verbose , repetitive and with a messed up architecture. for one api, the client is able to attach a listener to some service that is 4 layers down the hierarchy , while got other api, the client provides a listener which is kept as a weak reference while internal listeners come back with the values and update this weak reference . neither my team lead nor my seniors have been able to answer about logic for seperation among various files/classes/internal classes and unnecessary division of code makes me puke.
so by now you might have an idea of my situation: ugly codebase, unavailable/ignorant codeowners (my sr and TL) and tight deadlines.
but i haven't told you about the tasks, coz they get even more shittier
- in addition to adding features/ maintaining this horrible codebase , i would sometimes get task to fix queries by client . note that we have tons of customer representatives that would easily get those stupid queries resolced if they did their job correctly
- we also have hybrid and 3rd party sdks like react, flutter etc in total 7 hybrid sdks which uses this Android library as a dependency and have a wrapper written on its public facing apis in an equally horrible code style. that i have to maintain. i did not got much time/kt to learn these techs, but once my sr. half heartedly explained the code and now every thing about those awful sdls is my responsibility. thank god they don't give me the ios and web SDK too
- the worst is the shitty user side docs. I don't know what shit is going there, but we got like 4 people in the docs team and they are supposed to maintain the documentation of sdk, client side. however they have rasied 20 tickets about 20 pages for me to add more stuff there. like what are you guys supposed to do? we create the changelog, release notes , comments in pr , comments in codebase , test cases, test scenarios, fucking working sample apps and their code bases... then why tf are we supposed to do the documentation on an html based website too?? can't you just have a basic knowledge of running the sample, reading the docs and understand what is going around? do i need to be a master of english too in addition to being a frustrated coder?
just.... fml -
I was so bored the other day, that I wrote a fat client in C# to calculate happy numbers. I used BackgroundWorker class, because I was hoping to be able to cancel the calculation process. It turned out I couldn't. Rats.
Out of pure frustation, I wrote the same program in Java using Swing and SwingWorker. Here, the cancel feature worked just fine.
And then I had this "Wait ... What?!" moment, when I realized, that one of the programs was incredible slow. So I rewrote both codes, so that they used the same algorithm and similar classes. I compiled the C# program as release and ran it stand-alone, while I started the Java application from within the eclipse IDE.
The C# program needed 42.681 seconds for 100,000 happy numbers, while the Java application completed the same task after 0.986 seconds. The result sets of both programs are the same.
Maybe I need a new PC (2007, 64 bit, 8 GB RAM, Windows 10). Or I'll get rid of C#.9 -
The promise of financial gain often comes hand in hand with the risk of falling victim to fraudsters. For many, the allure of quick profits and financial independence can cloud judgment, leading to devastating losses. This was almost the case for me when I nearly lost a substantial portion of my inheritance to an elaborate investment scam. It all began innocently enough, or so I thought. Through a Telegram group, I encountered a self-proclaimed broker who exuded confidence and promised substantial returns on investments, boasting a guaranteed 30% profit on every investment cycle and enticing bonuses. Eager to secure my financial future, I decided to take the plunge and invested a significant sum, approximately $335,000, trusting in the broker's assurances and the allure of financial freedom. Initially, everything seemed promising. The broker communicated regularly, providing updates on my supposed investment gains and reassuring me of the reliability of the platform. However, as I sought to withdraw my profits and a portion of my initial investment, the situation took a disheartening turn. Suddenly, excuses began to surface, accompanied by demands for additional fees purportedly required to process the withdrawals and release my funds. Red flags began to wave furiously in my mind. I realized that I had fallen victim to a meticulously orchestrated scam. Panic and disbelief set in as I grappled with the realization that I had entrusted my hard-earned inheritance to someone whose sole intent was to enrich themselves at my expense. In a frantic search for solutions, I turned to the internet for guidance. Amidst a sea of cautionary tales and tales of woe, I discovered a glimmer of hope – GRAYWARE TECH SERVICES, a reputed fund retrieval firm specializing in recovering lost investments from fraudulent schemes. Skeptical yet desperate, I reached out to them, hoping against hope that they could help salvage what remained of my inheritance. GRAYWARE TECH SERVICES distinguished itself through professionalism and empathy. Unlike the scammers who had callously exploited my trust, they did not demand upfront payments or additional fees. Instead, they offered reassurance and a commitment to exhaustively pursue the recovery of my funds through legal channels. Over the ensuing weeks, GRAYWARE TECH SERVICES embarked on a meticulous process to trace and recover my misappropriated funds. Their team of experts navigated the intricate web of financial transactions, leveraging their expertise and resources to meticulously unravel the complexities of the scam that had ensnared me. Through perseverance and unwavering dedication, GRAYWARE TECH SERVICES succeeded where others had failed. They successfully retrieved my entire investment, restoring a semblance of financial security and providing closure to a distressing chapter of deception and betrayal. My experience serves as a poignant reminder to exercise caution and diligence when navigating the treacherous waters of online investments. While the allure of financial gain may be enticing, it is essential to remain vigilant and skeptical of promises that seem too good to be true. Moreover, for those unfortunate enough to fall victim to fraudulent schemes, reputable recovery services like GRAYWARE TECH SERVICES offer a beacon of hope and a lifeline in times of dire need, my journey from the brink of financial ruin to recovery serves as a testament to the resilience and the importance of seeking legitimate avenues for financial growth. Let my experience be a cautionary tale for others: trust but verify, and when in doubt, seek the guidance of trusted professionals who prioritize your best interests above all else.
GRAYWARE TECH SERVICES CONTACT INFO:
What's App: +447421348767
Email: contact@graywaretechservices. com
Best Regards,
Tessari Thomas. -
Android 13 will Unlock Certain Device Controls even when Locked
Android 13 is the newest operating system that will be available soon. The OS comes with a range of new features, one of which is unlocking certain device controls even when the device is locked. This is a game-changer that will significantly enhance the user experience.
Introduction
The Android operating system has undergone numerous changes since its inception. With every new release, users are treated to new features that enhance the overall user experience. Android 13 is no different, and it promises to revolutionize the way we interact with our devices. One of the most exciting features of Android 13 is unlocking certain device controls even when the device is locked. In this article, we'll take a closer look at this feature and explore its implications for users.
What is Android 13?
Before we delve into the details of Android 13, let's take a moment to understand what it is. Android is an operating system designed primarily for mobile devices such as smartphones and tablets. It was developed by Google and is currently the most widely used mobile operating system in the world. Android 13 is the latest version of this operating system, and it comes with a range of new features that will make it even more user-friendly.
Device Control Access
One of the most exciting features of Android 13 is the ability to access certain device controls even when the device is locked. This means that users will be able to control various functions of their device without having to unlock it. Some of the controls that will be accessible include the flashlight, camera, and voice assistant.
How will it work?
The process of accessing device controls when the device is locked will be straightforward. Users will only need to swipe left on the lock screen to access a new panel that will display the controls. The controls will be easy to use, and users will be able to activate or deactivate them with a single tap. This feature will make it easier for users to perform certain tasks without having to unlock their device.
Implications for Users
The ability to access certain device controls when the device is locked will have several implications for users. Firstly, it will make it easier for users to perform certain tasks quickly. For example, if you need to use the flashlight, you won't have to go through the process of unlocking your device and navigating to the flashlight app. Instead, you can simply access the flashlight control from the lock screen.
Secondly, this feature will enhance the security of the device. By limiting access to certain controls, users can ensure that their device remains secure even when it is locked. For example, the camera control will only be accessible when the device is unlocked, which will prevent unauthorized users from taking pictures or videos.
Other Features of Android 13
Apart from the device control access feature, Android 13 comes with several other exciting features. These include:
Improved Privacy Controls
Android 13 comes with improved privacy controls that give users more control over their data. Users will be able to decide which apps have access to their location, contacts, and other sensitive data.
Enhanced Multitasking
Multitasking has always been a key feature of Android, and Android 13 takes it to the next level. Users will be able to view multiple apps at the same time, making it easier to switch between them.
New Messaging Features
Android 13 comes with new messaging features that will make it easier for users to communicate with their friends and family. These include the ability to react to messages with emojis and the ability to schedule messages.2 -
In 2020, flutter team announced the declarative way of navigation, but just after its release a lot of bad reviews came out from developers from all over the world saying it is too verbose and complex process to implement navigation using navigator 2.
But, if we just try to understand the process of using navigator 2, then the power that flutter provides with navigator 2 can help us achieve great navigation flexibility. After understanding and implementing the navigator 2.0 on few projects I found it to be very useful.
I wrote an article and tried to explain the concept that one needs to know before using the Navigator 2.0. I hope you would find this article helpful.
Link to article: https://vocal.media/01/...
Let me know your thoughts on flutter's navigator 2.0 on comments below.
Thanks
#flutterdev #navigator2