Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Strong Sauce: Jul 2, 2003; You know I am not really your father.

SurgicalOntologist posted:

Given the rest of your post, I don't know if that supports that it's "extremely difficult to lose your changes". A new user might not know which flags are dangerous, considering that a lot of common commands require flags (so they might not think twice because something they saw on the web somewhere has a flag) plus that right there is an example of a not inexperienced someone losing a lot of changes. Yes, they did something stupid, but to someone learning git it might not scream "don't do this". I mean... don't be lazy? As a way to avoid losing data? A lot of people are lazy, unfortunately.

(Didn't mean to pick on you specifically but I wanted to share the newbie perspective that git is intimidating and the dissonance in this post illustrates it well)

I made the personal decision to learn Mercurial first and I'm not regretting it. I figure I'll have to learn git someday but hopefully all the version control concepts will be more intuitive then.

Come on. This is a bunk argument. When you learned Mercurial, how did you know the commands you entered in Mercurial would not be "dangerous"?

You literally have to know the commands: specifically `git push --force`, `git checkout .` and `git gc --prune`. The first command is not "bad" in the sense that you won't lose any of your changes, but you can risk messing up the branch for others if you modify commits that have been committed to the remote repository. The second command clears out all your unsaved changes. This is probably the only one that you may accidentally stumble upon, but you can save yourself a lot of grief if you commit often. The last one isn't even harmful unless you have something in a dangling commit. Even then you have to willingly execute a command that says "prune"

Strong Sauce fucked around with this message at 08:32 on Feb 13, 2014

# ? Feb 13, 2014 08:29

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 22:10

het: Nov 14, 2002; A dark black past
is my most valued
possession

pokeyman posted:

There's a version control thread in case anyone wants to bring discussion on over.

Seriously. I don't think we need to rehash the version control (git) argument every 10 pages.

# ? Feb 13, 2014 08:40

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

ClearCase.

So just shut up about git, ok? I'd kill for git.

# ? Feb 13, 2014 09:32

Extortionist: Aug 31, 2001; Leave the gun. Take the cannoli.

Ender.uNF posted:

ClearCase.

So just shut up about git, ok? I'd kill for git.

RCS.

In the rare case we have to share code with corporate, we have the luxury of using ClearCase. All local stuff is in RCS--and even then, a lot of production-critical code hasn't ever even been checked in.

# ? Feb 13, 2014 09:46

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

piratepilates posted:

I think I remember hearing that the CTO is trying to move to Git but I'll believe that when I see that, and I'll probably leave this place far before that happens.

I've seen the code that the teams I would be promoted in to write and it is not anything I want to be a part of.

If your organization is technically bankrupt, and you don't believe that you have the ability to bring about useful changes, and you don't think that the political will to have them happen is going to come any time soon, find a new job. Your liver will thank you :yotj:

# ? Feb 13, 2014 15:23

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Dear people who care about open-source: please do not submit issues containing the pettiest garbage I've ever seen.

# ? Feb 13, 2014 18:35

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Suspicious Dish posted:

Dear people who care about open-source: please do not submit issues containing the pettiest garbage I've ever seen.

I misread that as "prettiest" and was expecting some awesome ASCII art. Now I'm sad.

# ? Feb 13, 2014 18:43

astr0man: Feb 21, 2007; hollyeo deuroga

Suspicious Dish posted:

Dear people who care about open-source: please do not submit issues containing the pettiest garbage I've ever seen.

I really hope that guy submits the same issue report to the linux kernel maintainers :v:

# ? Feb 13, 2014 18:49

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Suspicious Dish posted:

Dear people who care about open-source: please do not submit issues containing the pettiest garbage I've ever seen.

One Asperger nerd's quixotic quest to make source code pretty.

# ? Feb 13, 2014 18:52

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Lumpy posted:

I misread that as "prettiest" and was expecting some awesome ASCII art. Now I'm sad.

Here you go then:

code:

    (\.-.
     | o \
     \O o \     .---,
      \o  o'--'`o  O/  (\_
   jgs '.o  O  o _.'    /o'.
         `"----'`       \ O \
                         |  o|
                        .'o  /
                     .-'o  O/
                    ( o  O.'
                     `"""`


          ___________
         [___________]
         /           \
        /~~^~^~^~^~^~^\
       |===============|
       | P I C K L E S |
       | ,-.   __      |
       | \ ,'-'. )     |
       |  '._'_;'      |
       ;===============;
    jgs \             /
         `"""""``""""`

# ? Feb 13, 2014 19:01

Superschaf: May 20, 2010

astr0man posted:

I really hope that guy submits the same issue report to the linux kernel maintainers

Probably:

# ? Feb 13, 2014 19:09

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Superschaf posted:

Probably:

Jesus.

https://github.com/facebook/conceal/issues/4

I think this might be a bot.

# ? Feb 13, 2014 19:13

Polio Vax Scene: Apr 5, 2009

It almost certainly is.

# ? Feb 13, 2014 19:27

QuarkJets: Sep 8, 2008

Suspicious Dish posted:

Dear people who care about open-source: please do not submit issues containing the pettiest garbage I've ever seen.

The way that he's posting those bug reports is loving awful, but he is pointing out legitimate violations of the C standard. It's doubtful that using a header guard like __DONG_BUTT_LOL is going to run into issues, but using leading underscores on all of your header guards may get you into trouble some day unless you know all of the the C libraries inside and out

# ? Feb 13, 2014 19:27

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Jabor posted:

Hacking up your workflow and dealing with multiple repositories because your tools can't cope with having a single one is a completely backwards way of "fixing" things.

Tools should serve the users, users should not have to bend over backwards to work around deficiencies in the tools.

I am not and was not saying anything about the relative virtues of different vcs'.

Presumably the tools being used on a project of that size would include something for dependency management? I don't think splitting balls of mud into versioned packages is especially backwards.

# ? Feb 13, 2014 19:31

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

QuarkJets posted:

The way that he's posting those bug reports is loving awful, but he is pointing out legitimate violations of the C standard. It's doubtful that using a header guard like __DONG_BUTT_LOL is going to run into issues, but using leading underscores on all of your header guards may get you into trouble some day unless you know all of the the C libraries inside and out

When I worked on the project a little while ago, we used #pragma once. I don't know why it was changed. Header guards suck, I agree. We should probably move back to #pragma once.

But honestly, the last time I remember an upcoming standard breaking existing code was when I had a macro called alignof that broke with C++11. It annoys me that they sanctioned off a bunch of off-limits identifiers and then introducing new ones ignoring the rules anyway.

# ? Feb 13, 2014 19:43

FamDav: Mar 29, 2008

Guess waterfall doesnt work in language design either.

# ? Feb 13, 2014 19:48

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

More of a process horror than a coding horror:

I've submitted some changes to an open-source project that uses SVN. I took the time to git-svn clone their repository, create multiple commits that are logically distinct and have detailed commit messages, and send these to their mailing list with git send-email (which creates one patch email per commit). These patches could be turned in to individual SVN commits without much difficulty. I also sent a link to my GitHub clone of their project, which allows for viewing each commit in a rather nice web interface.

The project's maintainers would like me to resend my changes as a single patch created by svn diff, by copying the current version of my files over the SVN trunk version :eng99:

They're not particularly interested in reviewing my changes until I do so.

I'm still a Git (or at least DVCS) zealot at heart, but I haven't had a chance to act as such in quite a while since I use Git for all of my own work and had only ever contributed to projects using Git or Mercurial. I was really trying to be nice, but this is definitely a case of "your project's use of SVN is forcing me to contribute in a suboptimal way", both in terms of me sending a huge unreadable diff and them having to review a bunch of changes all at once.

# ? Feb 14, 2014 01:10

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

Volmarias posted:

If your organization is technically bankrupt, and you don't believe that you have the ability to bring about useful changes, and you don't think that the political will to have them happen is going to come any time soon, find a new job. Your liver will thank you

It's my first job out of university, where I had no internships and didn't study hard. Not exactly like I can just up and leave yet, I'll see where I'm at after 6 months of working here or so.

There are so many things that could be done better here though, like introducing some actual regular automated testing, or having a QA department that tries to understand changes and their effects instead of just being the people who move changes to production, or stopping the development teams from writing code that has half the code commented out for no real reason, or source code without typos.

edit: a lot of the people are nice though, which is gonna be one of the sucky points of leaving.

edit: wanna know what code is in production/preproduction? Good luck with that, best course of action is guessing or trying to match up the history of each checkin on Sourcesafe to the labels that QA applies and try to see if there's any information about what was moved to where.

edit: you're supposed to check in the executables of any code you change, QA deploys that executable, no they won't check to see if the code even matches up to the executable, yes this has caused problems when people are trying to solve production issues or making further changes that break things.

piratepilates fucked around with this message at 01:38 on Feb 14, 2014

# ? Feb 14, 2014 01:33

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

piratepilates posted:

It's my first job out of university, where I had no internships and didn't study hard. Not exactly like I can just up and leave yet, I'll see where I'm at after 6 months of working here or so.

There are so many things that could be done better here though, like introducing some actual regular automated testing, or having a QA department that tries to understand changes and their effects instead of just being the people who move changes to production, or stopping the development teams from writing code that has half the code commented out for no real reason, or source code without typos.

edit: a lot of the people are nice though, which is gonna be one of the sucky points of leaving.

edit: wanna know what code is in production/preproduction? Good luck with that, best course of action is guessing or trying to match up the history of each checkin on Sourcesafe to the labels that QA applies and try to see if there's any information about what was moved to where.

edit: you're supposed to check in the executables of any code you change, QA deploys that executable, no they won't check to see if the code even matches up to the executable, yes this has caused problems when people are trying to solve production issues or making further changes that break things.

You work in a Developmestruction environment. Drink heavily to wash out everything "learned" here.

# ? Feb 14, 2014 02:29

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

Volmarias posted:

You work in a Developmestruction environment. Drink heavily to wash out everything "learned" here.

I have made about three or four little dumb mistakes from this one fix I made that have made it to production each time, affecting the work we do for a big whiny client that's always threatening to leave.

Each one would have been completely avoidable with a bit of automated testing and a QA department that did more QA.

The funny thing is my fix was to resolve an issue that brought down this client's site for all their customers, it was caused by a simple change to enable different order by options that no one must have tested that thoroughly (including the client), because if they did they would have noticed that it stops the site working completely for every user basically.

It's a pretty nicely run company with some nice people that isn't too soul sucking but drat, for a company that revolves around technology you'd think we'd do it better.

# ? Feb 14, 2014 02:50

Spatial: Nov 15, 2007

Got this today. :newlol:

code:

private int index;

public void callIndexInfo( int index )
{
    this.index = index;
    setSelectedIndex();
}

private void setSelectedIndex()
{
    switch (index)
    {
        case 0:
        {
            indexTabs.setSelectedIndex(index);
            break;
        }
        case 1:
        {
            indexTabs.setSelectedIndex(index);
            break;
        }
        case 2:
        {
            indexTabs.setSelectedIndex(index);
            break;
        }
        default:
        {
            indexTabs.setSelectedIndex(0);
            break;
        }
    }
}

# ? Feb 14, 2014 03:05

Nippashish: Nov 2, 2005; Let me see you dance!

I found this thing:

code:

        v[0,0] = 1
        v[1,0] = 1
        v[2,0] = 1
        v[3,0] = 1

// ...

        v[1106,0] = 1
        v[1107,0] = 1
        v[1108,0] = 1
        v[1109,0] = 1
        v[1110,0] = 1

Yes, they're all there. Yes, they're all 1.

# ? Feb 14, 2014 03:16

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Lysidas posted:

The project's maintainers would like me to resend my changes as a single patch created by svn diff, by copying the current version of my files over the SVN trunk version They're not particularly interested in reviewing my changes until I do so.

Well, they might be jerks, or they might just disagree with your assessment that they're logically separate commits. Communities have different standards for how fine-grained a commit should be: for example, if you're really making one user-visible change but need to tweak two different core interfaces to do so, some projects would like so see three commits, but others would like to see one. You can make a case either way. I have definitely seen developers (always git users) who split their commits too much, with the result that reverting the whole change or understanding the motivation for an individual commit becomes unnecessarily difficult.

Preparing the diff with svn diff is probably just about being able to apply the diff with patch -p0 instead of -p1. You can use --no-prefix for that, but yeah, this is a pretty trivial thing for them to be annoyed by.

# ? Feb 14, 2014 03:40

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

piratepilates posted:

I have made about three or four little dumb mistakes from this one fix I made that have made it to production each time, affecting the work we do for a big whiny client that's always threatening to leave.

Each one would have been completely avoidable with a bit of automated testing and a QA department that did more QA.

The funny thing is my fix was to resolve an issue that brought down this client's site for all their customers, it was caused by a simple change to enable different order by options that no one must have tested that thoroughly (including the client), because if they did they would have noticed that it stops the site working completely for every user basically.

It's a pretty nicely run company with some nice people that isn't too soul sucking but drat, for a company that revolves around technology you'd think we'd do it better.

Is anyone receptive to improving their processes? Automated builds and deployments are basically solved problems at this point. There's no need to have an insane home-grown process.

# ? Feb 14, 2014 03:41

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

Ithaqua posted:

Is anyone receptive to improving their processes? Automated builds and deployments are basically solved problems at this point. There's no need to have an insane home-grown process.

I believe the reason the programmers make the exes that are commited to vcs is because the company used to use a lot of VB3 applications, which for some unknown reason (I'm just blaming VB3) will just kinda break in weird ways sometimes when you compile it. I guess everyone just got used to it.

# ? Feb 14, 2014 03:49

Don Mega: Nov 26, 2005

One of my old coworkers loved to put for loops on one line.

code:

for (var i = 0; i < j; i++){ if ( i > 10) fartbong(); else if (i == 5) { yep(); still_one_line(); } else console.log('dog');}

Some were even longer than this.

# ? Feb 14, 2014 03:58

Coffee Mugshot: Jun 26, 2010; by Lowtax

Don Mega posted:

One of my old coworkers loved to put for loops on one line.
code:
for (var i = 0; i < j; i++){ if ( i > 10) fartbong(); else if (i == 5) { yep(); still_one_line(); } else console.log('dog');}
Some were even longer than this.

Looks like they are compensating for something.

# ? Feb 14, 2014 04:07

Lysidas: Jul 26, 2002; John Diefenbaker is a madman who thinks he's John Diefenbaker.; Pillbug

rjmccall posted:

Well, they might be jerks, or they might just disagree with your assessment that they're logically separate commits.

Fair point. It's definitely true that all of my patches should be applied in sequence, or none of them should be.

I separated things out into:

"add some innocuous plumbing to support the upcoming new feature"
"add new feature in a mostly-working but naive way that would be obvious to anyone associated with the project"
"fix some non-obvious problems that occur with a naive implementation of the new feature"

I did this purely for 'reviewability', to tell a consistent story about what needs to change for what reasons in order to support some new functionality. I could have easily squashed the commits in categories 2 and 3 together, but I was trying to be clear about why some additional complexity is required for what I implemented. It isn't bad to review all of this as a single diff; I was just mildly annoyed that I wasted the effort of making multiple commits and writing detailed messages about each one.

# ? Feb 14, 2014 04:28

Damiya: Jul 3, 2012

Ithaqua posted:

Is anyone receptive to improving their processes? Automated builds and deployments are basically solved problems at this point. There's no need to have an insane home-grown process.

hahahahaha

ha

haahahahahaha

Ha.

Your post is the horror here, officially.

Deployment and build is not a solved problem. There's always process and work to be done to adopt it to the constraints. There's no such thing as a magic "push button to build and deploy me" solution for everyone; if you've had the benefit of working with one, it's because someone built you a pipeline to do just that :P

Damiya fucked around with this message at 05:15 on Feb 14, 2014

# ? Feb 14, 2014 05:12

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Damiya posted:

hahahahaha

ha

haahahahahaha

Ha.

Your post is the horror here, officially.

Deployment and build is not a solved problem. There's always process and work to be done to adopt it to the constraints. There's no such thing as a magic "push button to build and deploy me" solution for everyone; if you've had the benefit of working with one, it's because someone built you a pipeline to do just that :P

I'm an ALM consultant and have spent the past year primarily consulting around devops, with the past 6 months or so hyper-focused on automated deployments. But you're probably right, my post is a horror and I must be totally ignorant on the subject.

I work mostly in the Microsoft toolset, but it's part of my job to be at least passingly familiar with what other platforms have available, because it's common to be asked "How does X compare to Y?", and saying "I don't know anything about Y" doesn't exactly inspire confidence.

There are tons of automated build and deployment tools. You still have to find the tool that will work best for you and invest some effort in getting the tools set up, but it's usually not onerous, and it's an investment that pays for itself in short order.

I'm predicting that in a few years, not having automated builds and automated deployment/packaging will be considered a horror akin to not having source control.

# ? Feb 14, 2014 05:31

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Lysidas posted:

Fair point. It's definitely true that all of my patches should be applied in sequence, or none of them should be.

Right. I mean, your split sounds like a very reasonable way to actually commit it, especially between the first patch and the later ones. But if I'm reviewing that � especially in a first-pass review, where I'm looking at your overall approach and thinking about how it fits in to my overarching plans � I almost certainly want to review all the changes together, because my thoughts about the design might change how you should do the plumbing, and I probably wouldn't consider accepting the plumbing without the follow-ups. And it doesn't bother me to see all the plumbing changes in the same patch, because I can recognize those pretty easily; as long as it's logically related, it's fine. So what I'd want to see in an ideal patch would be all the changes together, but with something in the email saying, "If you like this approach, I think it should be broken up into these three commits."

It definitely varies by community, though, especially for projects with fewer contributors. But the projects that are still on Subversion are generally the ones that've been around forever and might have hundreds of active committers � if nothing else, there's bound to be a ton of distributed configuration and tooling inertia around infrastructure crap like the choice of version control system.

# ? Feb 14, 2014 05:52

fritz: Jul 26, 2003

Lysidas posted:

The project's maintainers would like me to resend my changes as a single patch created by svn diff, by copying the current version of my files over the SVN trunk version They're not particularly interested in reviewing my changes until I do so.

Current job uses gerrit, and as far as I'm able to tell the process is whenever you want to put a set of changes they have to go in for review as one big patch, which means a lot of "git rebase -i HEAD~###".

# ? Feb 14, 2014 06:20

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

fritz posted:

Current job uses gerrit, and as far as I'm able to tell the process is whenever you want to put a set of changes they have to go in for review as one big patch, which means a lot of "git rebase -i HEAD~###".

You can just make the one big patch with git diff HEAD~###..; it doesn't help if they want changes to what you did in patch 1 of 17, but if they don't, great.

But generally you don't want to push changes exactly like you made them locally anyway.

# ? Feb 14, 2014 07:14

Steve French: Sep 8, 2003

rjmccall posted:

You can just make the one big patch with git diff HEAD~###..; it doesn't help if they want changes to what you did in patch 1 of 17, but if they don't, great.

But generally you don't want to push changes exactly like you made them locally anyway.

Have you used gerrit? It uses git; review is done on a per-commit basis. So if he wants his changes to be taken care of in a single review, he does have to do the big rebase-squash. That said, it is still possible to push a sequence of commits, have them reviewed individually, and then merge the whole enchilada at once when review of all the commits is done. But if any changes are requested to the commits, it'll be a pain for the review of descendant commits if it's already started, so best to avoid that.

# ? Feb 14, 2014 07:20

Space Kablooey: May 6, 2009

Nippashish posted:

I found this thing:

code:

        v[0,0] = 1
        v[1,0] = 1
        v[2,0] = 1
        v[3,0] = 1

// ...

        v[1106,0] = 1
        v[1107,0] = 1
        v[1108,0] = 1
        v[1109,0] = 1
        v[1110,0] = 1

Yes, they're all there. Yes, they're all 1.

Someone didn't want to work that day. Also, I'm imagining for some reason that it's a square matrix and suddenly it's even funnier.

# ? Feb 14, 2014 13:45

prefect: Sep 11, 2001; No one, Woodhouse.
No one.; Dead Man’s Band

Damiya posted:

hahahahaha

ha

haahahahahaha

Ha.

Your post is the horror here, officially.

Deployment and build is not a solved problem. There's always process and work to be done to adopt it to the constraints. There's no such thing as a magic "push button to build and deploy me" solution for everyone; if you've had the benefit of working with one, it's because someone built you a pipeline to do just that :P

It's not a solved problem like "install this one software package and everything is wonderful". It's just "solved" in that there are ways to do it well and these are not hidden secrets. There's always work to be done.

# ? Feb 14, 2014 14:04

Nippashish: Nov 2, 2005; Let me see you dance!

HardDisk posted:

Someone didn't want to work that day. Also, I'm imagining for some reason that it's a square matrix and suddenly it's even funnier.

It's not square, but there are 12 columns that are all set line by line. The other columns aren't all 1s though so it's not as funny.

# ? Feb 14, 2014 14:08

Sulla Faex: May 14, 2010; No man ever did me so much good, or enemy so much harm, but I repaid him with ENDLESS SHITPOSTING

It's too much to copy and paste but I've got a job at a small Italian dev company and the people I'm working with have far less programming experience and knowledge than me. Which is saying a hell of a lot since I don't have programming experience or knowledge. I've had to explain the concept of SQL injection so many times to blank stares that I've given up. Clearly they haven't understood it because I just had the misfortune of opening up a page (they can't even code PHP, that's how dire it is) that they were responsible for. I'll give you a quick run-down of the problems in a 250-line page that they didn't even write themselves, they just copy and pasted and hacked together like some sort of drunk, Mediterranean Dr Frankenstein.

1. Direct database insertion using unsanitised $_GETs.
2. They don't know how to format code so each line is on a different indentation based on where they've copy-and-pasted it from.
3. Multiple variable definitions per line, also based on copy-paste-modify.
4. They've left in code from when they were mucking around with the DB trying to figure out the table relationships. So there are DB queries and variable definitions/manipulations that never get used for anything, but are left in the page and in memory. I pointed it out two weeks ago and it's still there.
5. Contrary to what I implied in 4, they never actually figured out how the database is structured. I told them last week that they were inserting duplicate records into the enrolments table and it was causing problems. He says "But I need to enrol two users, the teacher and the student." "Yes, but that's not the table for that. This is the table for defining what types of enrolments the courses allow. So you've added two rows that say 'allow manual enrolments', when we only need one." It's still there and I emailed him today and he said he couldn't change it because he needs to enrol the teacher and the student. I explained in both Italian and English and I even showed him what the table looks like normally. Nope. I'll just change it myself and he won't notice because he doesn't know what his code is supposed to do anyway.
6. More $array_nuovo and $valori variable names than you can shake a stick at.
7. About 40% of the code is the same stdClass (they don't know what classes are so they've copy-pasted it from somewhere) of the same 40 properties with a single value shifted. They've just copy pasted it about 5 times, changing the one value each time.
8. About half of those 40 properties are manually set to null for DB upload.
9. Because they don't understand the table structure they do a foreach enrolment that will duplicate a single student's enrolment in the same course for every possible enrolment method. This is after they create duplicated enrolment methods.

This is all paid work, by the way, for a client. I think I may be single-handedly keeping the whole thing afloat...

Curiously enough, one of the guys, who confesses he isn't a programmer but a design/css guy, doesn't understand javascript, and since he doesn't understand css selectors either he just adds !important to literally every single definition he has. And since he doesn't know how to check error logs or validate html/css or anything, his css is full of broken poo poo like property definitions without specifying the property, because it's all on the same line and he doesn't realise that he's inserted a semi-colon in there instead of a comma.

And these are the italians lucky enough to find work. What a country.

# ? Feb 14, 2014 14:40

Adbot: ADBOT LOVES YOU

# ? Jun 3, 2024 22:10

kitten smoothie: Dec 29, 2001

Steve French posted:

Have you used gerrit? It uses git; review is done on a per-commit basis. So if he wants his changes to be taken care of in a single review, he does have to do the big rebase-squash. That said, it is still possible to push a sequence of commits, have them reviewed individually, and then merge the whole enchilada at once when review of all the commits is done. But if any changes are requested to the commits, it'll be a pain for the review of descendant commits if it's already started, so best to avoid that.

Within my company we require code review but we have no standard set on the tooling, teams can choose what they want. I recently switched from a product team that used Crucible to one which uses Gerrit, and seriously this rebsae-squash thing is the most infuriating thing ever.

Gerrit seems easy, as a submitter, so long as nobody requests any changes to your patch before merging.

My workflow with this is that I end up having my feature branch in which I work, then I have to have a second review branch off that where I do the rebase-squash dance. Then if there are changes I make them back in the feature branch, cherry pick that into the review branch, then do another squash to amend the bigass squashed commit.

Of course the cherry-picked commit will have its own new auto-generated change-ID, so when squashing I have to remember to copy-paste the original one to the bottom of the commit message or else Gerrit will still see the whole squashed thing as a brand new changeset and start a fresh review. :sigh:

# ? Feb 14, 2014 15:52

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »