Joey Beninghove - All Comments

re: Git/Branch-Per-Feature - Composable Deployments/Releases?

David Alpert — Thu, 11 Mar 2010 22:11:36 GMT

This is largely the same pattern my current team is using with Subversion; we have a build branch off the trunk that maps to your staging branch and we branch feature branches off the build branch then merge back into the build branch as they are ready to deploy to stage for testing.

That said, I think most of those branches and merges would go much faster and more smoothly w/ git than w/ svn. :-)

re: Git/Branch-Per-Feature - Composable Deployments/Releases?

Jon Kruger — Tue, 09 Mar 2010 17:44:49 GMT

+1 to the article that Dugald posted. I modeled my Git workflow off of that post and it is going great.

re: Git/Branch-Per-Feature - Composable Deployments/Releases?

Dugald — Tue, 09 Mar 2010 16:12:24 GMT

Yes, that article does a great a job outlining how things fit together. We use it, and then branch per feature, merging back into develop. Then, other developers can just pull from develop and do the same. I also like master as always having stable releases and being the goto for that. Then, everything else is fluid and temporary.

re: Git/Branch-Per-Feature - Composable Deployments/Releases?

joeyDotNet — Tue, 09 Mar 2010 16:01:22 GMT

Dugald,

Wow, that is a great article! Thanks! That model looks very attractive. I have thought about a using a long running "dev" branch somehow, but wasn't sure how best to fit it into the flow. This helps explain it a lot.

re: Git/Branch-Per-Feature - Composable Deployments/Releases?

Dugald — Tue, 09 Mar 2010 15:30:09 GMT

One thing I miss from your setup is a long-running 'development' branch. I use this branch to branch off features and then merge them back into the 'development' branch. We then keep development and master as the common branches pushed/pulled among developers. Staging seems to be serving that purpose for you, but I prefer the methodology in this post: http://nvie.com/git-model , where releases are in a separate branch for the release, which is then merged back into development and master.

re: Git/Branch-Per-Feature - Composable Deployments/Releases?

Jon Hilton — Tue, 09 Mar 2010 08:16:53 GMT

We've certainly seen benefits from approaching Git this way, especially as we also have TeamCity labelling builds for us.

The upshot is that if we have a problem with the deployed version (version number embedded in the dll) we can create a hotfix branch from that specific build without affecting any of our feature/master/staging branches.

The branch-per-feature approach also does a good job of ensuring developers work in a modular fashion rather than a scatter-gun, change twenty things at once assault on the code!

re: Funny question and response of the day

dmfiqjywewp — Sat, 13 Feb 2010 17:23:22 GMT

kVYln0 <a href="pjvzrnaptvlu.com/.../a>, [url=http://bjudssixwzbq.com/]bjudssixwzbq[/url], [link=http://edbbcxsoqeqx.com/]edbbcxsoqeqx[/link], http://zrvnvlinrida.com/

re: Scribbish Skin - For Subtext

renantech — Thu, 11 Feb 2010 02:16:10 GMT

I found your blog on Google and read a few of your other posts. I just added you to my Google News Reader. Keep up the good work.

I found that costumizing subtext plaftform is not easy but i really like it.

re: Guest Post: Suggestions for Effective Team Communication in a Virtual Environment

Julia Young — Wed, 21 Oct 2009 01:35:39 GMT

Thanks for a great list of tips. I too work in a mainly virtual environment with clients and colleagues in multiple locations. My colleagues and I keep IM on all time as an easy way to chat and ask odd questions. We have a habit of "beeping" each other first to see if we at our desks AND available before we go further. This really helps - we get the benefit of informal chat and also the courtesy of ensuring that it is good timing - like poking your head around the door. Sometimes we find that IM chat is too involved and we remind ourselves to pick up the phone or Skype.

re: Guest Post: Suggestions for Effective Team Communication in a Virtual Environment

Nancy Settle-Murphy — Tue, 20 Oct 2009 22:53:20 GMT

Great tips! One I would add: Consider both generational and cultural differences when creating a team communications plan. I find that many people "of a certain generation" really get thrown off track easily by frequent interruptions that IMing and texting can cause, while many younger folks I work with see email and even phone as "so yesterday." It's important to discuss the different communication options and make sure everyone is comfortable with the agreed-upon choices. Similar situation for cultural differences. Assume differences until similarities are proven is always the safest option.

re: Guest Post: Suggestions for Effective Team Communication in a Virtual Environment

laura w — Sat, 10 Oct 2009 19:06:16 GMT

I usually work with web-based applications like http://www.showdocument.com

I use it for sharing my designs and documents with partners and clients,

but i guess it can used for other purposes too. If you're looking for a free solution you should check it out.

- Laura W.

re: Guest Post: Suggestions for Effective Team Communication in a Virtual Environment

Karthik Hariharan — Sat, 10 Oct 2009 17:57:24 GMT

Sounds like a great set of rules/guidelines to follow.

Another good one is if you are on a mixed-environment team where some members are virtual and some are not, make everyone get on the phone separately when having a conference call rather than locals dialing in through a conference room.

Nothing is more annoying than being the one guy dialed in who can't get a word into the discussion.

re: Looking for some awesome .NET developers (work from home)

sonali — Fri, 25 Sep 2009 17:55:26 GMT

is there any upcoming opportunities for new comers

re: Smart Constructor Anti-Pattern

joeyDotNet — Thu, 03 Sep 2009 12:52:40 GMT

@Waheed,

Yes, I realized that perhaps I could have chosen a simpler example to explain the same thing. On the other hand, I often find it useful to see code samples that are as close to full, real world examples as possible. So my reason for using the MVP example above is simply because that was pretty close to an actual example I had seen in a real application.

Perhaps you could create a follow up post using a POCO example to illustrate this anti-pattern?

re: Smart Constructor Anti-Pattern

Waheed Sayed — Thu, 03 Sep 2009 08:44:57 GMT

Pardon me, I think you mis-chose your contrived example. The article title is about "Smart Constructor Anti-Pattern" and you have applied this anti-pattern on a special MVC case. Why didn't you use POCOs to show your idea. Should I learn MVC or MVP to understand an advice about writing a good constructor?