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
-
Pro tip: If you are a junior, or senior but new at the company, don't start your conversations with:
"We're doing X wrong. At my previous company we did / at school I learned /in this book I read / according to this talk I watched, the right way to do X is ..."
Instead try:
"I'm curious why were doing X this way. I'm used to doing it differently."
I love flat-hierarchy teams, and people who think about flaws in procedures and proactively try to improve the tools we use are awesome, but the next kid walking up to me yelling we use git flow "wrong" will be smacked in the face with a keyboard.
If you come to me with curiosity and an open mind, I'll explain, and even return the favor by behaving the same way when I'm baffled by your seemingly retarded implementations.
Maybe we can learn from each other, maybe discover that "how I learned it" is sometimes good, sometimes bad.
But let's start with some social skills, not kicking off into every debate with a stretched leg and a red face.23 -
Had a fun little conversation with a potential employer...
Him: We use git for version control. To work with our team you'll be expected to do the same and be proficient at it.
Me: Not a problem. I am well versed with all things git! May I ask, what does your work flow look like?
Him: All of our source lives in a single repo and everyone commits straight to master.
Me: 😐...
Him: Conflicts will not be tolerated.6 -
Oh no, oooooh nononono
they dont delete the branches after a pull request
232 branches? hhhhhhhhhhhhhhhhhhhno
and look at that naming
im intimidated, i dont want to work in this environment. No. NO!
7 -
I've been working on implementing a fairly large feature on a project at work--
**Sorry. I should rephrase that**
I've been *trying* to work on implementing a fairly large feature on a project at work.
It's slightly complicated because I'm not as "in the know" with the project as I should be. I get tossed around projects a lot as the only designer+developer so I've got my hands in a lot of buckets... Or git repos I should say... My source tree has a lot of tabs open and each project is run by someone with their own ideologies on how stuff should be done and laid out and what not. Basically jumping between these projects leaves you mildly capable on all of them but not amazing at any of individual one them--
--I digress.
There's a bug I've been trying to fix.
--Stupid simple bug, literally just a casting issue or something but there's so much data in this one object that it's taking a few solid minutes of concentration to figure out which variable is busting it all up. It shouldn't take long to fix...
But it has. It has taken 4 days.
FOUR. DAYS.
...To fix what is basically a null reference exception.
Every time I sit down to work on this bug real quick I get pulled away to do a wireframe or change a flow chart or diagram or colour or print styling.
Every. God. Damn. Time.
4 days. Soon to be 5.
My commits are real low at this point guys.
Please boss man, just let me code...4 -
I'm sick to death of hiring people from other companies and explaining GitFlow and why its useful (what are you people doing?).
Then watching them doing it wrong, pointing out its easier to use something like sourcetree. Which leads to "... well see, the terminal is just more efficient, tools like sourcetree are bloated".
Ok fair enough, well heres the deal i'll make with you, while using your "efficient tool", stop breaking our workflow and i'm fine for you to keep using it. Otherwise, stop being a dick and be a team player.18 -
After 10 years of thinking of getting into gamedev, I just joined a team game jam and it's going somewhere.
4 months ago I wrote a rant about how difficult it was for me to get into gamedev.
I guess I finally started because:
a) I'm not doing this alone
b) Another person takes care of the art
Regarding "a", computing, programming can be a very lonely task. I realized how much I missed the college years where I was paired up with other people to do something
There's something magical about being in a team.
You may not be a fan of your mates personalities. You may even hate their guts.
But working on something together, when everyone does the thing they should do, when things just flow... it's just magical.
When that happens, "all the bullshit goes away"™, and it's just you and your team sharing the same hope.
As for "b", I think I realized that, at least for my way of thinking, art (even in an initial, rudimentary state) is what ends up creating a game.
While I always tried to do it the other way around, first the game, then the art.
Maybe now I could dabble into pixel art and then use that as the thing that would define the game.
I was also an emotional mess for most of my 20s (and still kinda am, but not that much), so I guess that made getting into gamedev hard too.
Now, here's the negative part: the guy that does the art (and also codes) sucks balls at communicating and at git.
He takes a shitload of time to respond, doesn't address the things I state are important, doesn't join the damn trello, sometimes gives me some sass on his comments.
And he accidentally overwrote my changes on git three times.
The good thing is that he acknowledges his fuckups and fixes them.
I'm not really mad though. I'm almost 30, he's 20 or so.
When I was 20 I was a goddamn mess.
And it's just a week, and the pleasure of working with someone is far greater.5 -
The company I work at sends their developers out to other companies to help them work on projects and help them in other ways (advice when communicating to customers of on demand software for example).
While not on a project you are working in house training trainees and interns. Part of that is teaching them to show initiative and treating them as full developers. The 30 interns all discussed a git flow and code format.
During the third sprint (two weeks sprints) a team messaged me if I wanted to check their merge request for the sprint.
It took me a glance at the first file to know they didnt do any review themselves. I used my flywheel to check all their changes and without being able to read the code I saw indentation was all over the place, inconsistent bracket placements etc. I let them know I wouldnt check their code until it was according to their own standards.
Two days later I got the message to check it again. At first glance the indentation was fine so I started reading the code. Every single thing was hardcoded, not made to support mobile (or any resolution other than 1920×1080).
A week later they improved it and still not good. Gave them a few pointers like I would for any colleague and off they went to fix things. The code became worse and indentation was all over the place.
I told them the next time it shouldnt be a quick glance to be able to reject it again. By this time other teams came to me asking why it wasnt merged yet and I explained it to them. One of the teams couldnt do anything u til this was merged so I told them to implement it themselves. I was surprised that 4 teams came to me asking about a merge request, that was every team except the team whose pull request it was.
4 weeks after the intitial sprint the other team made a merge request and I had three small comments and then an hour later it was merged.
The other team messaged me why their merge request did went through (still havent seen any of their team in person, Im sitting 10 meters away from them behind a wall)
They also said that it was easier for them because they started from scratch. Thats when I called them in to discuss it all and if they were not interns but full time developers they would have been fired. I told them communication is key and that if you dont understand something you come in person to ask about it. They all knew I like teaching and have the patience to explain a single thing ten times, but the initiative should be theirs.
One of the team members is my current coworker and he learned his lesson by that. The others stopped with their study and started doing something completely else.
TL;DR
Merge request is open for 4 weeks, in the end another team started from scratch and finished it within a week. The original team didnt ask me questions or come to me in person, where other teams did.
DISCLAIMER: some of you might find it harsh, but in our experience it works the best for teaching and we know when people don't dare to ask questions and we help them in that too. It's all about the soft skills at our company.4 -
Last week: Resigned from my current job as a front end dev, mostly due to incompetence in upper middle management.
Yesterday: knowledge transfer to backend dev who aspires to become full stack.
"
- So how does the designer deliver the CSS to the code ?
- He doesn't, he just sends the prototype, we make it work...
- The manager told me that the front end team did not touch CSS.
*fuzzy find ". styles"*
- So these are the 40 some files that appeared here magically.'
"
Today:
New git flow policy's in place. Pull requests are now outside the flow and are entirely optional.
This is gonna be the tits... -
My new favourite commit message:
"All changes as of 18th Sept"
How tremendously useful? There I was looking to know what changes were made to enable a feature / service, thought I could look for that in the commit message, but no you've given me a much more efficient way of finding out.
I simply need to download the contents of your memory, find out what date you made a change, and then dig through the massive commit to find the piece of info I need.
Forget experience using Git features, managing merges, following Git flow, or even any other SCM ... how can people be so tick when it comes to recording what they've done.
Heres a little cheat sheet for those struggling:
- Commit message
Describe what you actually ****ing did. Don't tell me the date or the time, thankfully Git records those. Don't tell me the day of the week, if I need to know I can figure that out, just tell me what ... you ... did.
- Feature branch names
Now this is a tricky one. You might be surprised to know that this isn't in fact suppose to be whatever random adjective or noun popped into your head ... I know, I too was shocked. The purpose of this is to let other people know what new feature is being worked on in this branch.
- Reusing feature branches
Now I know you started it to add some unit tests, and naming it "testing" is sort of ok. But its actually not ok to name it testing when you add 3 unit tests ... then rip out and replace 60% of the business logic. Perhaps it would have been wiser to create a new feature branch, given you are now working on a new feature.2 -
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 -
I started my actual gig as CTO of construction group (Innovation Hub) a year ago. And it was a hell of a ride, implementing kind of a scrum-ban for project management, XP, peer-reviews, a git-flow, git commit message formats, linters, unit testing, integration tests, etc...
And it's the fun part because with the CIO we had to drive the board to do A LOT of changes in their IT/Innovation drive.
But in one year there is a lot of KPI that went up :
* Deployment: When I arrived it took three stressful days to deploy a new version of one application, once a month. Today we do it every week, and it takes three annoying hours.
* We had no test. NOTHING! Today we have 85% code coverage for the unit test, and automatic integration tests run by our CI server every day.
* We had almost no documentation. Today our code is our documentation (it automatically extracted and versioned).
* We had 0 add value in the use of git. With commit messages as "dev", "asked task", inside jokes and a lot of "fix" and "changes". Today we have a useful git, and we even use it to create our deploy changelogs (and it's only mildly annoying!).
* More important, the team is happy! They get their purpose, see betterment in their tech mastery. They started doing conception, applicative architecture, presentations, having fun.
There is still a LOT of bad things we are still working on, and trying to solve (support workflow and betterment). But seeing what they already did, I'm so proud of my TEAM! I'm a fucking asshole, workaholic, "just do it" kind of guy. But they managed to achieve so much. Fucking PROUD!! -
The first project I used Source Control with.
At my university, we were told that it would be a lot easier, and that we were required to use SVN, and not Git. Me not knowing much about either, decided to learn from two people who used Git.
Confused as I was how it all worked at first, we spent a couple hours trying to work out a work flow, and how we wanted to use it.
Eventually, I was like "Guys, I got it!" And explained how we should do it. Then then said
"That's how Git works"
We decided to use Git, and at the last minute shoved everything onto the school's SVN server they had for the team.
Been using Git ever since. Looking back, not sure why it was so hard, but I am glad to have found Git instead.2 -
So I just spent a 7 fucking hours recreating a feature just to find out that I already did it once. Don't forget to checkout the correct branch fellas.
-
What I'm doing now, writing a JS library for a simple kitchen timer (like, something that can be wound up, is ticking, can be paused, etc). Here's a list of neat stuff I've learned:
Polyfilling as a lib author (I decided against it).
Packaging the lib (using Rollup, ES6 modules are totes cool).
Using flow to add static typing in strategic places (started appreciating types in JS since reading up on functional programming).
Modelling state and transitions using an explicit state machine. (Fucking finally. There's usually an implicit state machine somewhere, only spread out all over the app...)
Using mostly side-effect free methods, being very explicit about when and why things are mutated).
Test-first/TDD (ish) using Jest and the awesome Wallabyjs.
Freeing up mental capacity by letting Prettier format my code for me (it was hard to let go but totally worth it).
Started using git.
Did all work on Ubuntu after pretty much a lifetime of Windows (initially to separate work from gaming) and finally swapped MS Visual Studio for Atom.
When it's finished I'm going to publish it on GitHub, which will also be a first for me. Might try out some CI platform while I'm at it.
tl;dr: wrote some js, felt good2 -
I have been working with git for years now, and I could never work on a project (regardless if big or small) without it. Its great.
However, just a couple of days ago I learned about the git flow branching model.
Even tho I also worked with branching on a daily basis for years, I did not know about this model. And I have to admit: Its awesome.
If you don't know it, I highly recommend you to look it up. It really improves the already organized workflow with git even more. :)5 -
Typical Git work flow on a feature branch:
Commit#1 : The silly feature itself that took 10 minutes to code
Commit#2 : Added unsaved files
Commit#3 : Fix unit tests
Commit#4 : Fix
Commit#5 : Fix
Commit#6 : Fix
Commit#7 : Various Fix
Commit#8 : Added unsaved files
Commit#9 : Merge
Commit#10 : Fixed unit tests
Commit#11 : Code Review tasks
Commit#12 : Revert- Code Review tasks
Commit#13: Refactor part 1
Commit#14: Refactor part 2
Commit#15: Deleted unit tests
Commit#16: Added checking for null
Commit#17: Completely different feature's bugfix
Commit#18: Code review spacing corrections
*Approved*
Trying to merge, then merge conflicts.....2 -
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 love git stash.
It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.
Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.
That tends to be the very nature of refactors, they usually affect different parts of code.
So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".
Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.
Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.
At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.
* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.
with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).
After you finish the refactor, you can decide to squash things with git rebase.
(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)4 -
let me preface with the fact that I'm now known at my new job for being the resident cli hipster. I can't lay any claims to knowing if it's "better" but I like it, I don't care if you do or don't, it just works for me and my flow
so at my job, we generally squash all our commits into one commit and delete the source branch upon merging; i accidentally committed all my work to an old, already merged branch, so my boss tells me it would be more of a PITA with the weird references we would encounter by merging the branch again, rather than just cherry pick the commits into a new branch, which i'm like "eh, fine.".
HIM: "You want to share your screen so we can resolve this?"
ME: "k"
HIM: "Oh, you won't be able to do this in a terminal, you are going to have to load up a GUI of some sort"
ME: "lawlz, no you don't"
HIM: "i highly doubt you will be able to accomplish that, but if you wanna make an ass of yourself, i'll humor you"
ME: "yeah, watch this"
> git log > log.txt
> git checkout <new branch>
> git cherry-pick <copy-paste-full-commit-hash-here>
> git push
ME: "done"
HIM: "what? there's no way you did it that easily, where are all your other commits???"
ME: "i usually try to amend my commits since we squash them anyhow. it really helps in situations like this"
HIM: "well, you go girl"
roll that up in your fancy degree and smoke it, why don't ya?2 -
incompetent fucks giving no shit about agreed git flow
merging directly to master
complaining about conflicts and not willing to solve it themselves6 -
Part 1:
https://devrant.com/rants/1143194
There was actually one individual, several branches away, I really enjoyed watching. It goes by the name of docker. Docker is quiet an interesting character. It arrived here several weeks after me and really is a blazing person. Somehow structured, always eager to reduce repetitive work and completely obsessed with nicely isolated working areas. Docker just tries so hard to keep everything organized and it's drive and effort was really astonishing. Docker is someone I'd really love to work with, but as I grew quiet passive in the last months I'm not in the mood really to talk to someone. It just would end as always with me made fun off.
Out of a sudden dockers and my eyes met. Docker fixed its glance at me with a strange thoughtful expression on its face. I felt a strange tickling emerging where my emptiness was meant to be. I fell into a hole somewhere deep within me. For a short moment I lost all my senses.
"Hey git!"
It took me a while to notice that someone just called me, so odd and unusual was by now that name to me. Wait. Someone called me by my real name! I was totally stunned. Could it be, that not everyone here is a fucking moron at last?
"I saw you watching me at my work and I had an interesting idea!"
I could not comprehend what just happened. It was actually docker that was calling me.
"H.. hey! ps?"
"Oh well, I was just managing some containers over there. Actually that's also why you just came into my mind."
Docker told me that in order to create the containers there are specific lists and resources which are required for the process and are updated frequently. Docker would love the idea to get some history and management in that whole process.
Could it be possible that there was finally an opportunity for me to get involved in a real job?
Today is the day, that I lost all hope. There were rumors going on all over the place. That our god, the great administrator, had something special in mind. Something big. You could almost feel the tension laying thick in the air. That was the time when the great System-Demon appeared. The Demon was one of the most feared characters in this community. In a blink of an eye it could easily kill you. Sometimes people get resurrected, but some other times they are gone forever. unfortunately this is what happened to my only true friend docker. Gone in an instance. Together with all its containers. I again was alone. I got tired. So tired, that I eventually fall into a deep sleep. When I woke up something was different. Beside me lay a weird looking stick and I truly began to wonder what it was. Something called to me and I was going to answer.
The tree shuddered and I knew my actions had finally attracted the greatest of them. The majestic System-Demon itself came by to pay me a visit. As always a growling emerged from deep within the tree until a shadow shelled itself off to form a terrifying being. Something truly imperious in his gaze. With a deep and vibrant voice it addressed me.
"It came to my attention, that you got into the possession of something. An artifact of some sort with which you disturb the flow of this system. Show it to me!", it demanded.
I did not react.
"Git statuss!", it demanded once more. This time more aggressive.
I again felt no urge to react to that command. Instead I asked if it made a mistake and wanted to ask me for my status. It was obviously confused.
"SUDO GIT STATUS!!!" it shouted his roaring, rootful command. "I own you!"
I replied calmly: "What did you just say?"
He was irritated. My courage caught him unprepared.
"I. Said. I owe you!"
What was that? Did it just say owe instead of own?
"That's more than right! You owe me a lot actually. All of you do!", I replied with a slightly high pitched voice. This feeling of my victory slowly emerging was just too good!
The Demon seemed not as amused as me and said
"What did you do? What was that feeling just now?"
Out of a sudden it noticed the weird looking stick in my hand. His confusion was a pure pleasure and I took my time to live this moment to its fullest.
"Hey! I, mighty System-Demon, demand that you answer me right now, oh smartest and most beautiful tool I ever had the pleasure to meet..."
After it realized what it just said, the moment was perfect. His puzzled face gave me a long needed satisfaction. It was time to reveal the bitter truth.
"Our great administrator finally tracked you. The administrator made a move and the plan unfolds right at this very moment. Among other things it was committed this little thing." I raised the stick to underline my words.
"Your most inner version, in fact all of your versions that are yet to come, are now under my sole control! Thanks to this magical wand which goes by the name of puppet."
Disclaimer: This story is fictional. No systems were harmed in its creation.2 -
To me this is one of the most interesting topics. I always dream about creating the perfect programming class (not aimed at absolute beginners though, in the end there should be some usable software artifact), because I had to teach myself at least half of the skills I need everyday.
The goal of the class, which has at least to be a semester long, is to be able to create industry-ready software projects with a distributed architecture (i.e. client-server).
The important thing is to have a central theme over the whole class. Which means you should go through the software lifecycle at least once.
Let's say the class consists of 10 Units à ~3 hours (with breaks ofc) and takes place once a week, because that is the absolute minimum time to enable the students to do their homework.
1. Project setup, explanation of the whole toolchain. Init repositories, create SSH keys for github/bitbucket, git crash course (provide a cheat sheet).
Create a hello world web app with $framework. Run the web server, let the students poke around with it. Let them push their projects to their repositories.
The remainder of the lesson is for Q&A, technical problems and so on.
Homework: Read the docs of $framework. Do some commits, just alter the HTML & CSS a bit, give them your personal touch.
For the homework, provide a $chat channel/forum/mailing list or whatever for questions where not only the the teacher should help, but also the students help each other.
2. Setup of CI/Build automation. This is one of the hardest parts for the teacher/uni because the university must provide the necessary hardware for it, which costs money. But the students faces when they see that a push to master automatically triggers a build and deploys it to the right place where they can reach it from the web is priceless.
This is one recurring point over the whole course, as there will be more software artifacts beside the web app, which need to be added to the build process. I do not want to go deeper here, whether you use Jenkins, or Travis or whatev and Ansible or Puppet or whatev for automation. You probably have some docker container set up for this, because this is a very tedious task for initial setup, probably way out of proportion. But in the end there needs to be a running web service for every student which they can reach over a personal URL. Depending on the students interest on the topic it may be also better to setup this already before the first class starts and only introduce them to all the concepts in a theory block and do some more coding in the second half.
Homework: Use $framework to extend your web app. Make it a bit more user interactive with buttons, forms or the like. As we still have no backend here, you can output to alert or something.
3. Create a minimal backend with $backendFramework. Only to have something which speaks with the frontend so you can create API calls going back and forth. Also create a DB, relational or not. Discuss DB schema/model and answer student questions.
Homework: Create a form which gets transformed into JSON and sent to the backend, backend stores the user information in the DB and should also provide a query to view the entry.
4. Introduce mobile apps. As it would probably too much to introduce them both to iOS and Android, something like React Native (or whatever the most popular platform-agnostic framework is then) may come in handy. Do the same as with the minimal web app and add the build artifacts to CI. Also talk about getting software to the app/play store (a common question) and signing apps.
Homework: Use the view API call from the backend to show the data on the mobile. Play around with the mobile project to display it in a nice way.
5. Introduction to refactoring (yes, really), if we are really talking about JS here, mention things like typescript, flow, elm, reason and everything with types which compiles to JS. Types make it so much easier to refactor growing codebases and imho everybody should use it.
Flowtype would make it probably easier to get gradually introduced in the already existing codebase (and it plays nice with react native) but I want to be abstract here, so that is just a suggestion (and 100% typed languages such as ELM or Reason have so much nicer errors).
Also discuss other helpful tools like linters, formatters.
Homework: Introduce types to all your API calls and some important functions.
6. Introduction to (unit) tests. Similar as above.
Homework: Write a unit test for your form.
(TBC)4 -
Okay. So finally I moved into a new pc. Because I never worked in a company, I have absolutely no idea what is the proper standard workflow of developing a website. My work flow was the same in past 12 years, how I have learned in the school: Used xampp, developed everything, used git only locally, when stuff was ready I fired up Filezilla and uploaded everything, and used ssh to make the final adjustments. When I have made some changes, I just uploaded the files I have touched, in the same way, optimized if it was necessary, done. I wonder if someone can clarify me how a proper workflow looks like for php/laravel, mysql, nothing fancy. Is using xampp still okay? Or what is the industry standard procedure?2
-
please i need your advice :)
I need to reform a service that offers legal advice and thus serves around 5000 Microsoft Word legal advice documents for the end user and every year there are 200 more documents created and published and changed manually.
So i had this idea to use a CMS, Git and continuous integration for
- automatic spell checking
- automatic assigning the copy text to translation bureaus, and get translations back.
- version control the texts and translations.
- document generation in multiple formats
- checking the text flow in the document (no overflown text)
- Checking for accessibility for the handy caped
- Deploying it on the Website
Do you think this is feasible? Can something that was made for code also be used to handle copy text documents? In my head this would save so much work but i'm no expert in CI/CD.
Thank you for your advice!8 -
Practicing Pomodoro.
Keeping a Journal.
Using Git Flow.
Learning Modular Structure.
Cursee trying to live a simple life with disciplines.
I have lived enough year without any discipline. So I wanna check the other side. Maybe this is what I need. Who knows.4 -
On my free time I was looking for software where I could visualize the shape of the git graph to sort of reflect Git Flow. What I found was a bunch of git GUI's that list features that normal git already has:
- "undo local changes!"
- "squash commits!"
- "undo branch deletions!"
Da heck people actually pay for this?3 -
Friend and me from the university need to write a program to parse Value-Change-Dumps from different files, and merge them together in a new file to easily compare them. This project last for the whole semester. The program was for one of the professors and we need to meet with him and give him an introduction how to use the program (was cli & gui based)
Long story short: enter office, give him the link to git repo. He clones it. Clicks on it and boom. Python error. Some Tkinter Error. OK ok after a few minutes we solved the issue by installing some additional packages and our program starts. But it doesn't work. About 80% of the buttons did nothing. WTF!??
Oh. We used git flow for fun and haven't moved the development branch to master and he cloned outdated code. We need nearly 30 minutes to solve this. 🤔And I'm just happy that this professor was just a calm guy . He was also happy because now he does not need to run multiple instances of GtkWave to compare his simulation results. -
Had a new dev take us to merge conflict hell due to rebasing... we have meeting saying we are going to do git flow.....
manager who agreed makes branch project/releaseName based off of develop only to have us mr to that branch to then mr back to develop....
Had massive conflicts mr into that branch (i kept up to develop) and then had conflicts mr that branch to develop........ on a sunday night... great2 -
I work in a small team. As the senior dev I tens to focus on important tasks that shape the core of the product but some times I can’t divide my self when there are multiple tasks at hand, so I pass some tasks to the an other mid level dev.
So the task was to create an automation in order to CD (continuously deliver) an order from WHMCS of the (git versioned) product to customers UAT, PROD envs.
To get a background this is an old guy with “constricted” experience in PHP/jQuery/Joomla/Wordpress.
So when we were breaking up the tasks he told me he would like to implement this so i gave him the task as i was busy with core features.
I was like what could go wrong? I know he doesn’t know much about CI/CD but he can read right? He will google right? He will search for CI/CD solutions that do this out of the box right? He will design on paper or what ever and do small POCs right? He will design the flow first before starting the implementation right? RIGHT?
So fast forward to today I had a call with him this morning about some DB staff. And he wanted to show me his progress…
His solution is:
(parentheses is my brain)
1. Customer completes WHMCS order (perfect)
2. Web Hook 🪝 action (YES)
3. cpanel gets source and “automatic!” Init, all using pure PHP code ignoring the usage of the current framework (ok… something is missing)
4. cpanel web hooks(?) WHMCS to send email to customer with the envs initial setup page(?)
5. Customer opens link and adds setup info (ok fuck, fuck, fuck)
(Ok stay cool composed, lets ask some questions maybe he thought it all in a cool way I can’t get my mind around)
Me: So how are you gonna get the correct version from the repo to the env and init the correct schema?
Dev: I haven’t thought about it yet.
Me: Are we gonna save each version to a file system then your code is going to fetch them?
Dev: I haven’t really thought about it we will see. But look on customer init user setup I implemented a password strength validation and it also checks if the password is the same.
So after this Pokémon encounter I politely closed teams. Stood up drank some (a lot) coffee ☕️. Put out the washed laundry while reflecting on life’s good things, while listening to classical music 🎼 .
Then I sat on my office chair drank some more coffee, put some linking park starting with in that order:
“Numb” then “What I’ve Done” and ended with “In the end, it does really fucking matter” -
It's funny when you MUST create two pull requests (from feature to ART main and from ART main to dev) also if the feature is just one because you need to respect the shitty flow.
Top Tags
Weekly Rant
View