101 reputation
2
bio website
location United States
age 43
visits member for 2 years, 6 months
seen Oct 23 at 3:59

Working amidst the ever merging & forever blurred realms of technocrat and troglodyte.


Sep
24
awarded  Autobiographer
Nov
20
comment How much difference does experience make?
I've had skillful, inexperienced as well as unskillful, inexperienced people work for me; the main difference is that unskillful, inexperienced people often do less damage (and less work) when setting out on the wrong path, and rarely argue or question when you tell them to change course. Skill coupled with inexperience therefore has a short-term risk, but hopefully longer-term benefit and payoff; and, I say "hopefully", since "experience" isn't implied with the passage of time and accumulation of failures.
Jan
31
comment Workflow: Using binary document formats in Git without locks (moving from subversion)
To minimize conflicts (while providing better cross-platform support (OSX/Win/Linux)), I use git w/ OpenDocument (OpenOffice/LibreOffice), using master documents (.odm), isolating styles in templates (.ott). Actual edits are in "included" documents (.odt), ranging from one to 15 pages, included into the master(s). Images and other assets are external, also "included" in the ".odt" files. Conflicts can still be merged (OpenDocument has better tool & utility support than MS Office); and since styles are external, you just merge content. Hooks (or jenkins) can generate pdf's after a git push.
Jan
31
comment What defines “software developer” role
...and yet I agree with you: "There's a difference between setting up Jenkins and setting up the whole build environment." Exactly. So, I guess it depends if you interpret the question literally (I did). Installing jenkins is an afternoon; setting up your make/ant/maven build takes days, and can easily turn into weeks, & must be done right. Good managers can break things down and delegate based on experience (in this respect, I've been a bad manager in the past, opting to do everything myself just because it would actually be faster. But that doesn't scale, and the "team" doesn't evolve.)
Jan
30
awarded  Supporter
Jan
30
comment What defines “software developer” role
These are NOT "senior developer" tasks. This (jenkins) is just following instructions. Senior dev's decide the path (from experience), junior dev's follow the path. If a junior developer complained about setting up jenkins, I'd look for another junior developer; the time it takes to set it up is less than the time to post this question and read the responses. (I know, because I've set up hudson/jenkins many times. And database replication. Sooo many times.) "Just do it," then you'll know how. If you never learn how to do anything, and expect to lead, you're nothing but a PHB in training.
Jan
30
comment What defines “software developer” role
Software development > writing code. If a software developer doesn't know how to setup/use and/or doesn't know the value of (a tool like) Jenkins, then by definition they would be a (very) junior software developer. Consider it on-the-job training, and count yourself lucky that you don't work in an environment where you have to run your own CI server on your own VM maintained on your own time in order to maintain a level of software quality that's expected, yet in practice discouraged if tools like these are disallowed in their (mostly manual) "processes".
Jun
28
comment What's the best way to handle multiple simultaneous “streams” of development in version control?
Absent decent version control, build/release tools & languages supporting dynamic deployment, all this sounds entirely reasonable. ... But given that we actually DO have these (git+CI(jenkins)+IoC/DI+modules(OSGi)+et-al.+ your fav' JVM-langue-du-jour) makes this sound just plain nuts. Spaghetti Factories are to be studied as an anti-pattern, not as an option. Proclaiming "if(feature)...elseif(feature2)..." as an intentional design/development/deployment model with redeeming value might give these poor php proj's/dev's a bad rep...
Jun
28
comment How can one use git-flow effectively on a project in which more than one major version is being maintained?
related (possibly duplicate) of stackoverflow.com/questions/8579056/…
Jun
11
comment How can one use git-flow effectively on a project in which more than one major version is being maintained?
This seems like the most practical solution, unless there is some tried-and-true trick using hotfixes or such that i'm not aware of. I've been searching for a way to introduce git-flow and still be able to (as an unfortunate prerequisite) keep our existing release model, where we have to maintain/develop older releases (not just hotfixes). So v5.1.x will stick around (w/ new features added, bugs fixed, etc) a couple years after v6.1.x is released. About 2-3 major versions supported and developed at any given time. But bug fixes need to be applied to each version where the bug exists.
Jun
11
comment How can one use git-flow effectively on a project in which more than one major version is being maintained?
But does this answer the question? Namely, does git-flow support a flexible release model as described in the question, or does one revert back to basic git commands? ("gitworkflows" describes basic git workflow usage, pre-git-flow.) Git-flow was created (ostensibly) to simplify git merge/branch processes, so teams (with varying degrees of git-fu prowess) could focus on coding and avoid time-consuming "mis-mergerment" mistakes. Is it possible w/ git-flow to maintain and develop v1.2.{1,2,3,..} at the same time as v2.5.{1,2,3,...}? Perhaps w/ long-term release branches? Or master1, master2,...?