terrible programmers: my god, it's full of chars

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »

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

Finster Dexter posted:

The issue I see here is that QA wants to test on a per-feature i.e. per-jira ticket basis. They don't test full releases, necessarily. They start testing a feature when we resolve the jira ticket and move on to other work. So, the problem I'm trying to avoid is where we end up with a branch that has poo poo from last sprint mixed in with poo poo from this sprint, so your timeline looks like:

v1 -- v2 -- v1 -- v2 -- v1

Instead, I want the timeline to be:

v1 -- v1 -- v1 -- v2 -- v2

Where v1 is Sprint v1 and v2 is Sprint v2.

so have qa test feature branches before you merge them back. you can branch from whatever point you feel is stable and doesn't have a ton of other crap you don't want qa to be simultaneously testing. if they discover problems, just fix them on your branch and repeat. you only get this interleaved history if you're repeatedly merging trunk into your feature branch, which is not something that just accidentally happens

i mean, i don't think that's the best development methodology. in my experience, work that takes a long time to complete (more than a week or two) tends to also be invasive and far-reaching. you need to land work like that as soon as you can so everyone can react to it, not keep it bottled up on an isolated branch for months only to spring it on the team during integration. and qa needs to be primarily testing integrated products; if they have enough resources to also test feature branches, great, but that's not a replacement

but if you're going to do this long-lived feature branch thing, it's not at all incompatible with having an unstable master with stable release branches

# ? Oct 21, 2016 21:34

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 19:52

Share Bear: Apr 27, 2004

- make own branch
- merge branch into master after code review and testing
- eventually make new branch from master, tag as a release branch
- late work gets merged into that branch
- release, remerging into master and making anyone on a newer branch merge conflict accepting theirs

this works pretty well, unless i am using the wrong git-verbs

# ? Oct 21, 2016 21:42

HoboMan: Nov 4, 2010

lol @ every mention of code review and testing in this discussion

E: i stumbled on a uuid that ends in 5acceed which almost looks like succeed and made me double-check i didn't just copy-paste the wrong thing

# ? Oct 21, 2016 21:44

Share Bear: Apr 27, 2004

HoboMan posted:

lol @ every mention of code review and testing in this discussion

E: i stumbled on a uuid that ends in 5acceed which almost looks like succeed and made me double-check i didn't just copy-paste the wrong thing

other people don't make fun of your code to your face? you don't either manually test or make automated tests for functionality?

# ? Oct 21, 2016 21:48

Shaggar: Apr 26, 2006

Finster Dexter posted:

The issue I see here is that QA wants to test on a per-feature i.e. per-jira ticket basis. They don't test full releases, necessarily. They start testing a feature when we resolve the jira ticket and move on to other work. So, the problem I'm trying to avoid is where we end up with a branch that has poo poo from last sprint mixed in with poo poo from this sprint, so your timeline looks like:

v1 -- v2 -- v1 -- v2 -- v1

Instead, I want the timeline to be:

v1 -- v1 -- v1 -- v2 -- v2

Where v1 is Sprint v1 and v2 is Sprint v2.

testing features individually is fine and good, but you also need to test the integration because they will absolutely step on each others toes at some point

# ? Oct 21, 2016 21:49

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

Share Bear posted:

- make own branch
- merge branch into master after code review and testing
- eventually make new branch from master, tag as a release branch
- late work gets merged into that branch
- release, remerging into master and making anyone on a newer branch merge conflict accepting theirs

this works pretty well, unless i am using the wrong git-verbs

why merge back from the release branch if the only things there are cherry-picked from master or ad-hoc fixes that you don't want in master? also, code review on the branch is fine, but testing needs to be done primarily on the integrated branches, i.e. master and release

# ? Oct 21, 2016 22:10

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

Shaggar posted:

testing features individually is fine and good, but you also need to test the integration because they will absolutely step on each others toes at some point

agreeing with shaggar

# ? Oct 21, 2016 22:11

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

We do feature branches (in hg) but it works because

- there are a total of 7 developers
- testing is on you and another developer looks it over
- its mostly web ui poo poo
- if a feature takes more than one week its a biggun
- features don't overlap. if pull requests do clash the later developer gets chosen to fix merge conflicts
- one guy reviews every singe pull request forever
- automated testing is only for a (small) part of the API. lol whats di

if you dont live in the same kind of hell then maybe feature branches might not be for you???

# ? Oct 21, 2016 22:36

VikingofRock: Aug 24, 2008

So I noticed that Haskell doesn't really seem to have a good symbolic mathematics library, which is surprising because typeclasses would make working with it so nice, and it would go so well with libraries like ad. So I'm kind of tempted to write my own, with some fairly-basic simplification (factoring out common factors, cancelling and combining like terms, etc).

How deep of a rabbit hole am I about to go down?

# ? Oct 21, 2016 22:46

Finster Dexter: Oct 20, 2014; Beyond is Finster's mad vision of Earth transformed.

JawnV6 posted:

if each ticket gets merged as a branch when complete, how are you getting v1-v2-v1 anyway?

Because multiple tickets per sprint

# ? Oct 21, 2016 22:50

Asymmetrikon: Oct 30, 2009; I believe you're a big dork!

VikingofRock posted:

How deep of a rabbit hole am I about to go down?

Congratulations on your new Haskell mathematics framework.

# ? Oct 21, 2016 22:59

Jerry Bindle: May 16, 2003

from what i remember of symbolic algebra stuff from TAoCP, some simplifications are really simple and obvious, however its a term-project level of difficulty to tune it to the point that it gives you results in appropriate formats in general. sounds fun!

# ? Oct 21, 2016 23:04

VikingofRock: Aug 24, 2008

Barnyard Protein posted:

from what i remember of symbolic algebra stuff from TAoCP, some simplifications are really simple and obvious, however its a term-project level of difficulty to tune it to the point that it gives you results in appropriate formats in general. sounds fun!

Ooh I didn't know that The Art of Computer Programming had a symbolic algebra section. I'll have to check it out. If anyone else has a good recommendation for a goof reference for this sort of thing I'd definitely be interested!

# ? Oct 21, 2016 23:12

Su-Su-Sudoko: Oct 25, 2007; what stands in the way becomes the way

rjmccall posted:

agreeing with shaggar

# ? Oct 21, 2016 23:35

Jerry Bindle: May 16, 2003

VikingofRock posted:

Ooh I didn't know that The Art of Computer Programming had a symbolic algebra section. I'll have to check it out. If anyone else has a good recommendation for a goof reference for this sort of thing I'd definitely be interested!

its used as a motivating example for trees in vol. 1, it has a short section about symbolic differentiation and the exercises go deeper into the topic

# ? Oct 21, 2016 23:48

VikingofRock: Aug 24, 2008

Barnyard Protein posted:

its used as a motivating example for trees in vol. 1, it has a short section about symbolic differentiation and the exercises go deeper into the topic

Cool, thanks for the recommendation. One of the reasons that I got on to this was actually because I wrote a toy automatic differentiator which should work with any Num type, and I wanted to show it off with symbolic expressions, but I couldn't find a good library for it.

# ? Oct 22, 2016 00:07

comedyblissoption: Mar 15, 2006

the talent deficit posted:

stable master, use feature flags and compiler defines to disable functionality not meant for release, every commit has to pass ci

this. also stable means there's been QA testing and code review before merging if that's part of your process.

git means you don't need the svn clusterfuck of trunk being the wild west and can actually have a stable master.

you test the integration of features before merging into master. you don't need a wild west to test things being integrated together.

# ? Oct 22, 2016 02:00

jony neuemonic: Nov 13, 2009

comedyblissoption posted:

you test the integration of features before merging into master. you don't need a wild west to test things being integrated together.

do you use a dedicated integration branch or just merge everything into a throwaway for testing before going to master?

# ? Oct 22, 2016 02:12

comedyblissoption: Mar 15, 2006

the typical strategy is we just have a feature branch per feature. you merge (which can be a rebase merge) the latest master into your feature branch before testing it and reviewing it. particular attention is paid to integration of features that have already made it into master if those features interact with the feature branch's feature.

if you have something that can't fit the above strategy because the features are intrinsically linked and so tightly woven together and none of them makes sense without the other and you can't put it in master in a way that makes sense even with a switch to toggle it off, then test the tightly woven features together into some throwaway integration branch off of master and don't merge any of it into master until it works together. this should be a very rare scenario though.

# ? Oct 22, 2016 02:30

comedyblissoption: Mar 15, 2006

a workflow of stable master and feature branching off master and only merging stuff when it's done and tested and reviewed has the following main benefits:

you don't have broken unfinished in-progress code that is checked in that slows you down and everyone else in many different ways
you don't have to worry about backing out unfinished and untested code that is intermixed with the code you want to keep when youre trying to create a stable release you want to go out to production

# ? Oct 22, 2016 02:35

Finster Dexter: Oct 20, 2014; Beyond is Finster's mad vision of Earth transformed.

comedyblissoption posted:

the typical strategy is we just have a feature branch per feature. you merge (which can be a rebase merge) the latest master into your feature branch before testing it and reviewing it. particular attention is paid to integration of features that have already made it into master if those features interact with the feature branch's feature.

if you have something that can't fit the above strategy because the features are intrinsically linked and so tightly woven together and none of them makes sense without the other and you can't put it in master in a way that makes sense even with a switch to toggle it off, then test the tightly woven features together into some throwaway integration branch off of master and don't merge any of it into master until it works together. this should be a very rare scenario though.

Yeah, I'm thinking this is the way to go. It's simple, and I think the extra step of rebasing a finished feature branch off the current master before passing to QA will be helpful to avoid integration issues.

# ? Oct 22, 2016 03:10

jony neuemonic: Nov 13, 2009

comedyblissoption posted:

the typical strategy is we just have a feature branch per feature. you merge (which can be a rebase merge) the latest master into your feature branch before testing it and reviewing it. particular attention is paid to integration of features that have already made it into master if those features interact with the feature branch's feature.

if you have something that can't fit the above strategy because the features are intrinsically linked and so tightly woven together and none of them makes sense without the other and you can't put it in master in a way that makes sense even with a switch to toggle it off, then test the tightly woven features together into some throwaway integration branch off of master and don't merge any of it into master until it works together. this should be a very rare scenario though.

makes sense. i was thinking that there could be issues integrating the individual features together even with a rebase onto master pre-merge, but if that's happening all the time then there's probably an issue with how features are being scoped or tight coupling in the codebase.

# ? Oct 22, 2016 03:40

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

long-lived feature branches loving suck. they discourage refactoring and make you spend goddamn forever merging things.

it's much better to structure changes so that they have no effect on the operation of the application (until the last part of the feature is complete and brings everything together), and then aggressively merge things into master. that way master always remains in a (theoretically) releasable state, but you don't have to deal with any painful merges or much in the way of conflicts.

# ? Oct 22, 2016 03:46

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

yeah we try to encourage a one commit per pr ratio with additional commits only to fix issues raised in code review

we also try to merge regularly (multiple times per day) so there's no long lived feature branches

# ? Oct 22, 2016 05:20

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

lightweight feature branches are great

# ? Oct 22, 2016 12:54

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

our architect sits near to me and he has been trying to get the developers to split features into smalles sub features. i'm trying to get them to make smaller commits. similar goals, really.

like if we need to have a list of people in some view, one easy place to split the task into two would be backend/frontend, then the backend might be split into database (migration)/business logic
on the frontend, you could just slap some placeholder components on the view that are not populated with anything, then you could implement data fetching and populate the ui. and at least one separate task could be validation, if the user can edit the list.

but no, i'm going to make all those changes in series and in one go, taking the whole sprint and then commit a massive diff that touches everything and is lovely to review, and the testers will not have time to test the feature, so it's not "done done"

# ? Oct 22, 2016 13:20

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Wheany posted:

our architect sits near to me and he has been trying to get the developers to split features into smalles sub features. i'm trying to get them to make smaller commits. similar goals, really.

like if we need to have a list of people in some view, one easy place to split the task into two would be backend/frontend, then the backend might be split into database (migration)/business logic
on the frontend, you could just slap some placeholder components on the view that are not populated with anything, then you could implement data fetching and populate the ui. and at least one separate task could be validation, if the user can edit the list.

but no, i'm going to make all those changes in series and in one go, taking the whole sprint and then commit a massive diff that touches everything and is lovely to review, and the testers will not have time to test the feature, so it's not "done done"

i've gotten in the habit of rejecting pull requests that touch too many things. 10x and i got into a little slapfight about it earlier this week because of course he thought it made sense to submit a pull request that touched 20 files across 4 different features.

# ? Oct 22, 2016 13:39

Jerry Bindle: May 16, 2003

yeah all the source control branching methodologies in the world won't help you if you don't work with reasonable people who are effective at communicating their actions and intentions

# ? Oct 22, 2016 15:21

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

reading through some of the go compiler and I find this:

https://golang.org/src/go/ast/ast.go#L34

code:

    34	// All node types implement the Node interface.
    35	type Node interface {
    36		Pos() token.Pos // position of first character belonging to the node
    37		End() token.Pos // position of first character immediately after the node
    38	}
    39	
    40	// All expression nodes implement the Expr interface.
    41	type Expr interface {
    42		Node
    43		exprNode()
    44	}
    45	
    46	// All statement nodes implement the Stmt interface.
    47	type Stmt interface {
    48		Node
    49		stmtNode()
    50	}
    51	
    52	// All declaration nodes implement the Decl interface.
    53	type Decl interface {
    54		Node
    55		declNode()
    56	}

Hm weird, I wonder what the impleme....

code:

   792	func (*BadStmt) stmtNode()        {}
   793	func (*DeclStmt) stmtNode()       {}
   794	func (*EmptyStmt) stmtNode()      {}
   795	func (*LabeledStmt) stmtNode()    {}
   796	func (*ExprStmt) stmtNode()       {}
   797	func (*SendStmt) stmtNode()       {}
   798	func (*IncDecStmt) stmtNode()     {}
   799	func (*AssignStmt) stmtNode()     {}
   800	func (*GoStmt) stmtNode()         {}
   801	func (*DeferStmt) stmtNode()      {}
   802	func (*ReturnStmt) stmtNode()     {}
   803	func (*BranchStmt) stmtNode()     {}
   804	func (*BlockStmt) stmtNode()      {}
   805	func (*IfStmt) stmtNode()         {}
   806	func (*CaseClause) stmtNode()     {}
   807	func (*SwitchStmt) stmtNode()     {}
   808	func (*TypeSwitchStmt) stmtNode() {}
   809	func (*CommClause) stmtNode()     {}
   810	func (*SelectStmt) stmtNode()     {}
   811	func (*ForStmt) stmtNode()        {}
   812	func (*RangeStmt) stmtNode()      {}

YOU'RE RIGHT THERE IN THE AST. You can fix this you idiots! They could remove so much confusing and pointless boilerplate by just adding a union type that is just a macro that expands into this ridiculous interface bullshit. They wouldn't need to touch the runtime or anything.

# ? Oct 22, 2016 15:51

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

i mean, i know ASTs have lots of empty statements like that but they're really just using it to enforce constraints that the type system could easily be handling for them.

# ? Oct 22, 2016 15:54

Jerry Bindle: May 16, 2003

is this AST built directly after parsing? if so it'd explain stuff like `BadStmt`

oh nvm i get it now i think, lol

Jerry Bindle fucked around with this message at 17:24 on Oct 22, 2016

# ? Oct 22, 2016 17:17

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

yeah, it looks pretty tied up with the parser. my real point is that theyre using interfaces in an rear end backwards way in order to approximate useful features from languages with good typing, and yet...

Honestly though, that code is pretty easy to read.

DONT THREAD ON ME fucked around with this message at 17:32 on Oct 22, 2016

# ? Oct 22, 2016 17:26

redleader: Aug 18, 2005; Engage according to operational parameters

lol if you don't regularly dump multi-thousand line changes that touch all over the codebase directly to trunk

# ? Oct 22, 2016 21:33

Bloody: Mar 3, 2013

lol if your work code base is multi thousand line in the first place

# ? Oct 22, 2016 21:38

Deep Dish Fuckfest: Sep 6, 2006; Advanced
Computer Touching; Toilet Rascal

lol if you work

# ? Oct 22, 2016 21:38

redleader: Aug 18, 2005; Engage according to operational parameters

we don't do
- branches
- feature flags
- automated testing
- a hell of a lot of manual testing
- dev/uat/staging environments (usually)

we're still in business because most developments don't touch anywhere near the same code, because we actually do code review, and because our competitors are somehow worse

# ? Oct 22, 2016 21:40

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

yeah i've finally been bitten by the org-mode bug. this is a big deal for me because note taking and organization has always been really really hard for me. i really do keep everything i know in my head. if something is really really really important, i'll send myself an email (probably with no subject) as a note. that's for only the most important things.

now within a few days i'm loving outlining everything. it's wild. being able to link into my code is such an amazing feature. i've basically stopped using fuzzy search for buffers / files because i have everything i'm working on linked into my outline, arranged in whatever hierarchy happens to make sense to my brain, thank you very much.

i'm so into it that i'm already about 30% of the way through writing a tool that will translate Rally's rest api into org's internal AST. Once it's done I'll be able to edit my Kanban poo poo from org mode. Joyous day.

buffer management still sucks though.

# ? Oct 22, 2016 21:41

Soricidus: Oct 21, 2010; freedom-hating statist shill

redleader posted:

lol if you don't regularly dump multi-thousand line changes that touch all over the codebase directly to trunk

I like to make sure I have at least a dozen whitespace changes for every semantic change in a commit. it helps conceal how bad my code is.

# ? Oct 22, 2016 21:41

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

i have two mega commits building up and they've defied all of my attempts to break them up into smaller pieces. but i'm pretty dedicated to not producing 2,000 line commits so i've got to figure something out.

# ? Oct 22, 2016 21:43

Adbot: ADBOT LOVES YOU

# ? May 25, 2024 19:52

cinci zoo sniper: Mar 15, 2013

im going to dump a big commit soon. for the first time, and hopefully for the last time.

# ? Oct 22, 2016 21:45

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > terrible programmers: my god, it's full of chars

«‹›1446 »