Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10377 > unrolled thread

Two More Very General Consulting Question

Back to article view | Back to comp.lang.java.programmer

Contents

  Two More Very General Consulting Question Novice <novice@example..com> - 2011-11-30 21:00 +0000
    Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-30 21:45 +0000
      Re: Two More Very General Consulting Question Novice <novice@example..com> - 2011-11-30 23:00 +0000
        Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-01 03:06 +0000
          Re: Two More Very General Consulting Question Novice <novice@example..com> - 2011-12-06 15:24 +0000
            Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-06 20:59 +0000
        Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-07 05:45 -0800
          Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-07 18:58 +0000
            Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-07 18:57 -0500
              Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-07 20:33 -0400
                Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-08 16:04 +0000
                  Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-09 06:53 -0400
                    Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-09 12:51 +0000
                      Re: Two More Very General Consulting Question Lars Enderin <lars.enderin@telia.com> - 2011-12-09 17:26 +0100
                        Re: Two More Very General Consulting Question Martin Gregorie <martin@address-in-sig.invalid> - 2011-12-09 23:12 +0000
                        Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-10 12:00 +0000
                      Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-10 19:53 +0000
                        Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-11 00:04 +0000
                    Re: Two More Very General Consulting Question Tom Anderson <twic@urchin.earth.li> - 2011-12-10 20:12 +0000
                    Re: Two More Very General Consulting Question Jim Janney <jjanney@shell.xmission.com> - 2011-12-12 03:05 -0700
                      Re: Two More Very General Consulting Question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-12 06:39 -0400
              Re: Two More Very General Consulting Question Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-12-07 20:55 -0600
                Re: Two More Very General Consulting Question Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-12-09 10:42 +0000
          Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-07 18:48 -0500
      Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-07 05:43 -0800
    Re: Two More Very General Consulting Question Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 20:15 -0500
    Re: Two More Very General Consulting Question Roedy Green <see_website@mindprod.com.invalid> - 2011-12-06 16:45 -0800

Page 1 of 2  [1] 2  Next page →

#10377 — Two More Very General Consulting Question

Things are moving alone with respect to the contract that I mentioned in 
another thread. We're still in initial discussions but it feels 
promising. Two basic questions have come up.

--

First question: They are asking about my availability.

If the truth be told, I have nothing else on my plate right now except 
looking for work and there is nothing in the short term future either. 
I'd like to say "I can dedicate myself to your project 100% starting 
tomorrow morning" but am concerned that this may make me look bad. They 
might well get the impression that I am so awful at what I do that I 
can't find any customers.  

Is there a good way to answer the availability question that basically 
says I can give them my full attention immediately without making me look 
like I'm really inept?

--

Second question: They are asking for examples of Java work that I have 
done. 

Unfortunately, I don't have much paid work to show him. A complicating 
factor is that, while I keep copies of the code I've written forever, I 
had a hard drive crash a couple of years back in which I've lost a fair 
bit of my code.

I can only recall doing two paying Java contracts so far. 

The more recent contract I did got cancelled during the development cycle 
due to cost issues and was never implemented. The non-disclosure 
agreement for that work is still presumably in effect so I couldn't show 
them the code which I still have even if I want to. I could contact that 
customer and find out if the NDA is still valid and I'm sure I'd get a 
quick answer. Should I do that?

An earlier example of paid code was a Java applet that I did as a 
subcontract for a friend a while back. He had written a Lotus Notes 
application and wanted an applet to do graphing of performance 
characteristics of the customer's products. That Lotus Notes page was 
gone the last time I went to the website several years ago so the applet 
is also presumably long gone, replaced by something else. I didn't sign 
an NDA as far as I recall but the friend who gave me the contract may 
have. I can find out easily enough but the applet would be pretty crude 
by any modern standards even if the NDA wasn't an issue. I hadn't been 
coding Java long and Swing wasn't even out yet so it is in AWT. (I later 
made a Swing version but it's never been run outside of my IDE.)

If unpaid work can constitute a reasonable example - and I personally 
think it should - I did one decent Java application and a servlet for a 
friend for an NGO he was involved in for free, strictly out of interest 
in doing it. However, he left the organization shortly after that and 
they abandoned the work I'd done when he left. I didn't sign an NDA for 
that work but I'm not sure if I should feel free to show the code to 
someone else. That's assuming I didn't lose that code in the crash.

Aside from that, all the code I've got which survived the hard drive 
crash, is code I've written for myself that has never really seen the 
light of day outside of my IDE or isn't likely to be of interest to him 
since he wants an application, not a servlet. I've got a few complete 
programs, most of which are not very good in terms of style and design. 
Should I offer him the best of those?

Or am I best to confess my relative inexperience and hope for the best?

I haven't claimed any great expertise yet - and don't intend to - but I 
don't particularly want to emphasize how little paying Java experience I 
have either. What's my best way forward?

-- 
Novice

[toc] | [next] | [standalone]

#10381

On Wed, 30 Nov 2011 21:00:28 +0000, Novice wrote:

> An earlier example of paid code was a Java applet that I did as a
> subcontract for a friend a while back. He had written a Lotus Notes
> application and wanted an applet to do graphing of performance
> characteristics of the customer's products. That Lotus Notes page was
> gone the last time I went to the website several years ago so the applet
> is also presumably long gone, replaced by something else. I didn't sign
> an NDA as far as I recall but the friend who gave me the contract may
> have. I can find out easily enough but the applet would be pretty crude
> by any modern standards even if the NDA wasn't an issue. I hadn't been
> coding Java long and Swing wasn't even out yet so it is in AWT. (I later
> made a Swing version but it's never been run outside of my IDE.)
>
That sounds like a reasonable starting point. Being willing and able to 
explain why you were dissatisfied enough with the AWT version to create 
the Swing version and why it is an improvement sounds like a good plot to 
me.

However, I'd strongly suggest that you don't mention the crash because 
IMO losing anything in a disk crash shows a certain carelessness. Here 
I'm assuming that you now have an adequate backup scheme that is used 
regularly and rigorously and that, preferably, you also are familiar with 
and use a source version control system for any code you care about. Can 
you explain your backup and version control strategy if asked?


> If unpaid work can constitute a reasonable example - and I personally
> think it should - I did one decent Java application and a servlet for a
> friend for an NGO he was involved in for free, strictly out of interest
> in doing it. However, he left the organization shortly after that and
> they abandoned the work I'd done when he left. I didn't sign an NDA for
> that work but I'm not sure if I should feel free to show the code to
> someone else. That's assuming I didn't lose that code in the crash.
>
Same comments as above.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#10385

Martin Gregorie <martin@address-in-sig.invalid> wrote in
news:jb685f$5an$3@localhost.localdomain: 

> On Wed, 30 Nov 2011 21:00:28 +0000, Novice wrote:
> 
>> An earlier example of paid code was a Java applet that I did as a
>> subcontract for a friend a while back. He had written a Lotus Notes
>> application and wanted an applet to do graphing of performance
>> characteristics of the customer's products. That Lotus Notes page was
>> gone the last time I went to the website several years ago so the
>> applet is also presumably long gone, replaced by something else. I
>> didn't sign an NDA as far as I recall but the friend who gave me the
>> contract may have. I can find out easily enough but the applet would
>> be pretty crude by any modern standards even if the NDA wasn't an
>> issue. I hadn't been coding Java long and Swing wasn't even out yet
>> so it is in AWT. (I later made a Swing version but it's never been
>> run outside of my IDE.) 
>>
> That sounds like a reasonable starting point. Being willing and able
> to explain why you were dissatisfied enough with the AWT version to
> create the Swing version and why it is an improvement sounds like a
> good plot to me.
> 

Thanks for taking the time to make comments, Martin!

I've gone into the code since writing my post and found that I confused 
two different applets. The one that I modified to use Swing was not a 
paid applet; it was a little demonstration applet that I wrote for 
someone to illustrate something we were talking about socially. It 
eventually led to me getting a contract with him so it was well worth the 
brief time that I spent on it but it's almost too trivial to show anyone. 

That applet that did the graphing was considerably more sophisticated and 
never got changed to Swing because I basically just drew on Graphics 
context with drawLine(); there were no other GUI classes used beyond a 
Redraw button and a checkbox that gave the user an option with regards to 
displaying the data. (There was a lot of calculating going on within that 
applet, especially with regards to scaling the graphs suitably, so it 
wasn't a trivial applet by any means. It just doesn't do anything 
terribly interesting in the GUI aside from drawing curves.)

> However, I'd strongly suggest that you don't mention the crash because
> IMO losing anything in a disk crash shows a certain carelessness. 

I had the same concern. But that IS why I lost a bunch of my code. How do 
I explain that lost code in the best possible way WITHOUT admitting to 
the crash? 

> Here
> I'm assuming that you now have an adequate backup scheme that is used 
> regularly and rigorously and that, preferably, you also are familiar
> with and use a source version control system for any code you care
> about. Can you explain your backup and version control strategy if
> asked? 
>
In all honesty, I am still just limping along in the hope that the drive 
won't crash again. I have a considerably newer computer so my odds are 
better than they were with the aging computer that crashed but that's 
clearly no guarantee that I won't have another crash. 

I still don't have an adequate backup strategy and I know of version 
control but don't use it. I simply haven't had the spare cash to do 
something about that. I hope to do something about that as I make more 
money on contracts but it might be a while as I have some debts that need 
to be paid off.... 
 
> 
>> If unpaid work can constitute a reasonable example - and I personally
>> think it should - I did one decent Java application and a servlet for
>> a friend for an NGO he was involved in for free, strictly out of
>> interest in doing it. However, he left the organization shortly after
>> that and they abandoned the work I'd done when he left. I didn't sign
>> an NDA for that work but I'm not sure if I should feel free to show
>> the code to someone else. That's assuming I didn't lose that code in
>> the crash. 
>>
> Same comments as above.
>  
> 





-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10394

On Wed, 30 Nov 2011 23:00:17 +0000, Novice wrote:

> I had the same concern. But that IS why I lost a bunch of my code. How
> do I explain that lost code in the best possible way WITHOUT admitting
> to the crash?
>
With difficulty, which is why I suggested you avoid mentioning it.
 
> In all honesty, I am still just limping along in the hope that the drive
> won't crash again. I have a considerably newer computer so my odds are
> better than they were with the aging computer that crashed but that's
> clearly no guarantee that I won't have another crash.
>
If there's a possibility of remote working in the contract this might be 
an issue: if you're storing the contracted work on your own computer then 
it *must* be backed up, version control or no version control. If the 
client uses a version control system then you'll probably be expected to 
use it too and that would most likely apply wherever you may be doing the 
work. As there are a variety of version control systems, both proprietary 
and Open Source, in common use you'll probably get away without knowing 
the details of a specific one, but some familiarity with what they all do 
and the common terminology would be useful. IMO doing a non-trivial 
coding project without using version control falls into the same category 
as writing C without understanding make or Java without knowing ant, 
maven or an IDE.

> I still don't have an adequate backup strategy and I know of version
> control but don't use it. I simply haven't had the spare cash to do
> something about that. I hope to do something about that as I make more
> money on contracts but it might be a while as I have some debts that
> need to be paid off....
>
In this day and age I'd accept a project backup scheme based on a cycle 
of two or more SD cards. That is, provided the most recent backup is 
somewhere offline, preferably in a fire safe or at least in a shed at the 
end of the garden. It would be a pretty big project if its documentation, 
source and test data wouldn't fit on a 2GB SD card - much bigger than a 
one person job for sure.

I'm currently using USB disk drives for system backups and doing the 
backups with rsync for speed. A 30GB backup to a blank USB 2.0 drive 
takes 3-5 hours, but a weekly rsync run to capture changes takes under 20 
minutes. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#10556

Martin Gregorie <martin@address-in-sig.invalid> wrote in
news:jb6r0j$agt$2@localhost.localdomain: 

> On Wed, 30 Nov 2011 23:00:17 +0000, Novice wrote:
> 
>> I had the same concern. But that IS why I lost a bunch of my code.
>> How do I explain that lost code in the best possible way WITHOUT
>> admitting to the crash?
>>
> With difficulty, which is why I suggested you avoid mentioning it.
>  
>> In all honesty, I am still just limping along in the hope that the
>> drive won't crash again. I have a considerably newer computer so my
>> odds are better than they were with the aging computer that crashed
>> but that's clearly no guarantee that I won't have another crash.
>>
> If there's a possibility of remote working in the contract this might
> be an issue: if you're storing the contracted work on your own
> computer then it *must* be backed up, version control or no version
> control. If the client uses a version control system then you'll
> probably be expected to use it too and that would most likely apply
> wherever you may be doing the work. As there are a variety of version
> control systems, both proprietary and Open Source, in common use
> you'll probably get away without knowing the details of a specific
> one, but some familiarity with what they all do and the common
> terminology would be useful. IMO doing a non-trivial coding project
> without using version control falls into the same category as writing
> C without understanding make or Java without knowing ant, maven or an
> IDE. 
> 
First, sorry for the delay in responding. 

What you've said makes eminent sense. Having backups is something I'd 
want if I were the client. I'm long overdue to have a proper system of 
backups and versioning so now is the time to get into that. Part of my 
delay in replying was starting to look at the tools available and 
skimming some tutorials on the subject. So far, it looks like I'll use 
Subclipse since it integrates nicely with my existing Eclipse set up. 
 
>> I still don't have an adequate backup strategy and I know of version
>> control but don't use it. I simply haven't had the spare cash to do
>> something about that. I hope to do something about that as I make
>> more money on contracts but it might be a while as I have some debts
>> that need to be paid off....
>>
> In this day and age I'd accept a project backup scheme based on a
> cycle of two or more SD cards. That is, provided the most recent
> backup is somewhere offline, preferably in a fire safe or at least in
> a shed at the end of the garden. It would be a pretty big project if
> its documentation, source and test data wouldn't fit on a 2GB SD card
> - much bigger than a one person job for sure.
> 
> I'm currently using USB disk drives for system backups and doing the 
> backups with rsync for speed. A 30GB backup to a blank USB 2.0 drive 
> takes 3-5 hours, but a weekly rsync run to capture changes takes under
> 20 minutes. 
> 
> 

I'm thinking of storing my backups and versions offsite if I can find a 
secure and affordable place to put them. Finding free webhosting isn't 
too hard so maybe I can find something comparable for my code. Of course 
I will want to lock it down pretty tightly so that others can't pilfer 
it.

-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10567

On Tue, 06 Dec 2011 15:24:24 +0000, Novice wrote:

> I'm thinking of storing my backups and versions offsite if I can find a
> secure and affordable place to put them. Finding free webhosting isn't
> too hard so maybe I can find something comparable for my code. Of course
> I will want to lock it down pretty tightly so that others can't pilfer
> it.
>
Here's what I do, which may give you some ideas.

- everything I want to keep is under version control except web sites,
  which are developed here under a local server and FTPed to the public
  server, which therefore doubles as off-site backup.

- my version control repository is on an always-on server. There is only
  one repository for all work done on my local network.

- the server does an automatic overnight compressed backup of its
  filing system to a permanently online USB disk which is big enough
  to hold several backups. It runs for 2 hours. The disk is unmounted
  and spun down when not in use, so is unsafe against fires or big mains
  spikes. Its prime purpose is protection against data loss by finger
  trouble.  

- on a weekly basis the filing systems of each machine on the local net
  is copied to a second USB drive using rsync. Backup time is 10-20
  minutes per machine. This disk holds a single backup per machine and
  is kept in a fire safe.

The effect of this is they there is at least one online backup of 
everything plus a second offline copy that is never more than a week old. 

Total additional cost backups is the price of two USB drives. The backup 
utilities (rsync, tar and gzip) are free. Backups are controlled by shell 
scripts I developed to my own requirements and cron, the OS job scheduler.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#10589

On Wed, 30 Nov 2011 23:00:17 +0000 (UTC), Novice <novice@example..com>
wrote, quoted or indirectly quoted someone who said :

> I simply haven't had the spare cash to do 
>something about that. 

IT will set you back $6 a month if you don't host the SVN server
yourself.

See http://mindprod.com/jgloss/wushnet.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.
 

[toc] | [prev] | [next] | [standalone]

#10597

On Wed, 7 Dec 2011, Roedy Green wrote:

> On Wed, 30 Nov 2011 21:45:19 +0000 (UTC), Martin Gregorie
> <martin@address-in-sig.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>> However, I'd strongly suggest that you don't mention the crash because 
>> IMO losing anything in a disk crash shows a certain carelessness.

Indeed it does.

> see http://mindprod.com/jgloss/subversion.html
> http://mindprod.com/jgloss/tortoisesubversion.html

I would say that in this day and age, it is no longer appropriate to 
suggest Subversion. Subversion was the best tool available for a long 
time, and it is still perfectly serviceable, but there are better tools 
available now; projects using it can keep using it without worry, but 
there is no reason for a new project, or a project adopting a new source 
control system, to start using it.

The better tools i mention include this one:

http://mercurial.selenic.com/

And another popular one that i can't in all honesty recommend.

These tools are free, featureful, reliable, straightforward, portable, 
widely used, widely documented, and interoperable with each other and with 
Subversion (sometimes via bridges, otherwise via repository conversion). 
There is every reason to use them, and no reason not to.

On Wed, 7 Dec 2011, Roedy Green wrote:

> On Wed, 30 Nov 2011 23:00:17 +0000 (UTC), Novice <novice@example..com>
> wrote, quoted or indirectly quoted someone who said :
>
>> I simply haven't had the spare cash to do something about that.
>
> IT will set you back $6 a month if you don't host the SVN server
> yourself.
>
> See http://mindprod.com/jgloss/wushnet.html

It will set you back nothing at all if you don't host the Mercurial server 
yourself:

https://bitbucket.org/

There is *no* excuse for not using source control at all, and there hasn't 
been for years. There is now *no* excuse for not having an offsite backup 
of your source control system.

tom

-- 
We discovered in Nature's work a pattern of sloppiness, indifference to
basic scholarly standards, and flagrant errors so numerous they completely
invalidated the results. -- Encyclopaedia Britannica

[toc] | [prev] | [next] | [standalone]

#10599

On 12/7/2011 1:58 PM, Tom Anderson wrote:
> On Wed, 7 Dec 2011, Roedy Green wrote:
>> see http://mindprod.com/jgloss/subversion.html
>> http://mindprod.com/jgloss/tortoisesubversion.html
>
> I would say that in this day and age, it is no longer appropriate to
> suggest Subversion. Subversion was the best tool available for a long
> time, and it is still perfectly serviceable, but there are better tools
> available now; projects using it can keep using it without worry, but
> there is no reason for a new project, or a project adopting a new source
> control system, to start using it.

VCS is an area where fashion often seems to overshadow
facts.

When SVN came out then CVS was suddenly so oldfashioned - you
could not use a VCS without atomic commits without being
considered stone age.

I have never seen an actual problem due to CVS not having
atomic commits. Or even read about. Maybe the problem was
not that important.

Today with hg and git then SVN is suddenly so oldfashioned - you
can not use a non-distributed VCS without being
considered stone age.

The distributed part is great for code that is being worked on
by completely independent organizations (read: large open source
projects).

But most people do not really have that need.

So hg and git are great tools. But there are actually
not anything wrong by using SVN or even CVS for most
contexts.

And knowing a specific software is actually a good
reason to continue keep using it.

Arne

[toc] | [prev] | [next] | [standalone]

#10600

On 11-12-07 07:57 PM, Arne Vajhøj wrote:
> On 12/7/2011 1:58 PM, Tom Anderson wrote:
>> On Wed, 7 Dec 2011, Roedy Green wrote:
>>> see http://mindprod.com/jgloss/subversion.html
>>> http://mindprod.com/jgloss/tortoisesubversion.html
>>
>> I would say that in this day and age, it is no longer appropriate to
>> suggest Subversion. Subversion was the best tool available for a long
>> time, and it is still perfectly serviceable, but there are better tools
>> available now; projects using it can keep using it without worry, but
>> there is no reason for a new project, or a project adopting a new source
>> control system, to start using it.
> 
> VCS is an area where fashion often seems to overshadow
> facts.
> 
> When SVN came out then CVS was suddenly so oldfashioned - you
> could not use a VCS without atomic commits without being
> considered stone age.
> 
> I have never seen an actual problem due to CVS not having
> atomic commits. Or even read about. Maybe the problem was
> not that important.
> 
> Today with hg and git then SVN is suddenly so oldfashioned - you
> can not use a non-distributed VCS without being
> considered stone age.
> 
> The distributed part is great for code that is being worked on
> by completely independent organizations (read: large open source
> projects).
> 
> But most people do not really have that need.
> 
> So hg and git are great tools. But there are actually
> not anything wrong by using SVN or even CVS for most
> contexts.
> 
> And knowing a specific software is actually a good
> reason to continue keep using it.
> 
> Arne

I'm with you on this, Arne. You beat me to it actually. 100 percent of
the version control scenarios that I have encountered in business in
over a decade require a "central" or "master" repository and an official
keeper of the flame. Branches have to be strictly decreed and
controlled, lest anarchy result. If git or Mercurial were used in place
of SVN, the manner in which they'd have to be used would offer zero
benefits over SVN.

I agree that there are plenty of scenarios that benefit from a
distributed VCS. But a whole bunch don't.

AHS

[toc] | [prev] | [next] | [standalone]

#10606

[Multipart message — attachments visible in raw view] — view raw

On Wed, 7 Dec 2011, Arved Sandstrom wrote:

> On 11-12-07 07:57 PM, Arne Vajhøj wrote:
>> On 12/7/2011 1:58 PM, Tom Anderson wrote:
>>> On Wed, 7 Dec 2011, Roedy Green wrote:
>>>> see http://mindprod.com/jgloss/subversion.html
>>>> http://mindprod.com/jgloss/tortoisesubversion.html
>>>
>>> I would say that in this day and age, it is no longer appropriate to 
>>> suggest Subversion. Subversion was the best tool available for a long 
>>> time, and it is still perfectly serviceable, but there are better 
>>> tools available now; projects using it can keep using it without 
>>> worry, but there is no reason for a new project, or a project adopting 
>>> a new source control system, to start using it.
>>
>> VCS is an area where fashion often seems to overshadow
>> facts.
>>
>> Today with hg and git then SVN is suddenly so oldfashioned - you can 
>> not use a non-distributed VCS without being considered stone age.
>>
>> The distributed part is great for code that is being worked on by 
>> completely independent organizations (read: large open source 
>> projects).
>>
>> But most people do not really have that need.
>
> I'm with you on this, Arne. You beat me to it actually. 100 percent of 
> the version control scenarios that I have encountered in business in 
> over a decade require a "central" or "master" repository and an official 
> keeper of the flame. Branches have to be strictly decreed and 
> controlled, lest anarchy result. If git or Mercurial were used in place 
> of SVN, the manner in which they'd have to be used would offer zero 
> benefits over SVN.
>
> I agree that there are plenty of scenarios that benefit from a 
> distributed VCS. But a whole bunch don't.

Incorrect. Have either of you actually used a DVCS for any length of time 
on a team project?

It's true that a great many projects don't need the anarchic 
fully-distributed mode of operation that DVCS allows. In fact, the only 
one i know of that really uses it is the Linux kernel; even other open 
source projects using DVCS have a fairly centralised workflow.

But the thing that DVCS gives you that is invaluable to everyone, 
everywhere, is local commits. You can work, commit, work, commit, work, 
realise you've gone wrong and roll back to your last commit, work, commit, 
work, have an idea, commit, try something experimental, learn something, 
roll back to your last commit, work, commit, and so on. All locally, 
without having to push up to the server, make a zip file, make a patch, or 
do any other monkeying about. All inside the version control system.

It is a massively useful thing to be able to do.

Arved mentioned that "branches have to be strictly decreed and controlled, 
lest anarchy result", and that's true, but with one qualification - it's 
true of branches *on the server*. People can make whatever branches they 
fancy locally, as long as they don't trouble anyone else with them. That 
can be useful too, on occasion.

My team moved over to Git a while ago. We have a traditional centralised 
workflow: we work locally, and push and pull to a central server. We don't 
push and pull to each other. Even for us, a DVCS has been a great tool.

Even if you don't make use of the new powers bestowed on you by a DVCS 
(which would be a great mistake), the current crop of DVCSs offer 
evolutionary improvements on Subversion. They don't need a server, so 
they're easier to set up and manage. They make creating new repositories 
much easier. They're faster. They are, incredibly, usually more compact (a 
Hg/Git repository + working copy is usually smaller than a Svn working 
copy alone - recall that Svn stores a pristine, uncompressed, copy of each 
and every file). They don't litter your working copy with millions of 
secret directories.

The only downside is that the graphical tools, and integration with other 
systems, is not always as good as for Subversion. But note that "not as 
good" means "80-90% as good". I use Git and Mercurial through their 
Eclipse plugins, and they are basically as good as the Subversion or CVS 
plugins. They each have a few warts, but they are purely cosmetic.

So, no, the noise about DVCS is not fashion. It is firmly grounded in 
facts.

tom

-- 
We'll never win by being like them. Our best tactic is to be
better. Better necessarily means different. -- Jon Rentzsch

[toc] | [prev] | [next] | [standalone]

#10619

On 11-12-08 12:04 PM, Tom Anderson wrote:
> On Wed, 7 Dec 2011, Arved Sandstrom wrote:
> 
>> On 11-12-07 07:57 PM, Arne Vajhøj wrote:
>>> On 12/7/2011 1:58 PM, Tom Anderson wrote:
>>>> On Wed, 7 Dec 2011, Roedy Green wrote:
>>>>> see http://mindprod.com/jgloss/subversion.html
>>>>> http://mindprod.com/jgloss/tortoisesubversion.html
>>>>
>>>> I would say that in this day and age, it is no longer appropriate to
>>>> suggest Subversion. Subversion was the best tool available for a
>>>> long time, and it is still perfectly serviceable, but there are
>>>> better tools available now; projects using it can keep using it
>>>> without worry, but there is no reason for a new project, or a
>>>> project adopting a new source control system, to start using it.
>>>
>>> VCS is an area where fashion often seems to overshadow
>>> facts.
>>>
>>> Today with hg and git then SVN is suddenly so oldfashioned - you can
>>> not use a non-distributed VCS without being considered stone age.
>>>
>>> The distributed part is great for code that is being worked on by
>>> completely independent organizations (read: large open source projects).
>>>
>>> But most people do not really have that need.
>>
>> I'm with you on this, Arne. You beat me to it actually. 100 percent of
>> the version control scenarios that I have encountered in business in
>> over a decade require a "central" or "master" repository and an
>> official keeper of the flame. Branches have to be strictly decreed and
>> controlled, lest anarchy result. If git or Mercurial were used in
>> place of SVN, the manner in which they'd have to be used would offer
>> zero benefits over SVN.
>>
>> I agree that there are plenty of scenarios that benefit from a
>> distributed VCS. But a whole bunch don't.
> 
> Incorrect. Have either of you actually used a DVCS for any length of
> time on a team project?

In order to acquire facility with Mercurial and Git I use them myself,
on my own work (which may be real work, but doesn't involve anyone
else). I've used Mercurial for about 3 years, have used Git less and
maybe for about 2 years.

I haven't done any open source teamed projects within the past few
years. There have been zero opportunities to use Mercurial or Git on the
job, *with a team*. I have actually tried, three times in as many years,
to make one or the other happen.

> It's true that a great many projects don't need the anarchic
> fully-distributed mode of operation that DVCS allows. In fact, the only
> one i know of that really uses it is the Linux kernel; even other open
> source projects using DVCS have a fairly centralised workflow.
> 
> But the thing that DVCS gives you that is invaluable to everyone,
> everywhere, is local commits. You can work, commit, work, commit, work,
> realise you've gone wrong and roll back to your last commit, work,
> commit, work, have an idea, commit, try something experimental, learn
> something, roll back to your last commit, work, commit, and so on. All
> locally, without having to push up to the server, make a zip file, make
> a patch, or do any other monkeying about. All inside the version control
> system.
> 
> It is a massively useful thing to be able to do.

Tom, no need to sell _me_, I am sold already. :-) That's why I have
tried three times in as many years to introduce a DVCS in a real work
environment. Each time it's been a SVN shop (which is part of the
problem, they've already got SVN).

I'll tell you why it's failed:

1. It's (legitimately) hard to convince a client that a centralized DVCS
model is significantly better than a SVN setup. It has to be
_significantly_ better because they are facing a migration of history [1];

2. Very few arguments that have to do with benefits for _developers_ are
important. You don't have to convince developers, you have to convince
managers.

2. Only the developers amongst the client personnel understand your
"local commits" argument, or the other one (better branching/merging
than SVN). Problem is, very few of the managers get it, and _they_ are
the ones that need to be convinced.

I've encountered my share of client managers that actually don't see
your description of local commits as being a good thing, unlike you or
me or most developers. To them that all sounds like coders wasting time
at best, and unsupervised work at worst.

> Arved mentioned that "branches have to be strictly decreed and
> controlled, lest anarchy result", and that's true, but with one
> qualification - it's true of branches *on the server*. People can make
> whatever branches they fancy locally, as long as they don't trouble
> anyone else with them. That can be useful too, on occasion.
> 
> My team moved over to Git a while ago. We have a traditional centralised
> workflow: we work locally, and push and pull to a central server. We
> don't push and pull to each other. Even for us, a DVCS has been a great
> tool.
> 
> Even if you don't make use of the new powers bestowed on you by a DVCS
> (which would be a great mistake), the current crop of DVCSs offer
> evolutionary improvements on Subversion. They don't need a server, so
> they're easier to set up and manage. They make creating new repositories
> much easier. They're faster. They are, incredibly, usually more compact
> (a Hg/Git repository + working copy is usually smaller than a Svn
> working copy alone - recall that Svn stores a pristine, uncompressed,
> copy of each and every file). They don't litter your working copy with
> millions of secret directories.
> 
> The only downside is that the graphical tools, and integration with
> other systems, is not always as good as for Subversion. But note that
> "not as good" means "80-90% as good". I use Git and Mercurial through
> their Eclipse plugins, and they are basically as good as the Subversion
> or CVS plugins. They each have a few warts, but they are purely cosmetic.
> 
> So, no, the noise about DVCS is not fashion. It is firmly grounded in
> facts.
> 
> tom

Again, _I_ agree with you 100 percent. But Tom, if you read what I
originally wrote, I referred to "business scenarios that I have
encountered", "the manner in which they'd have to be used", and things
of that nature. I wasn't referring to technical superiority of hg or git
over svn, or lack thereof, or vice versa. In fact I'm satisfied that
hg/git are always at least as good as svn, and usually better.

It's simply that I have yet to encounter a team environment where the
managers bought this. I've made three attempts in as many years;
everyone else I've worked with in the past 5 years, say, would have been
as difficult to convince as those three teams.

And bear in mind that quite a few of the arguments in favour of DVCS,
unless pitched very carefully (and sometimes de-emphasized), either
don't interest managers, or they don't like what they hear. I've also
encountered a couple of organizational version control types who have to
be carefully talked to so they don't feel threatened by "developer
empowerment", and once you've semi-successfully done that then they
don't care enough about DVCS to be champions either.

Let me put it this way, and maybe this helps to make my point: "they
make creating new repositories much easier", as you mentioned above, is
_not_ a selling point in many client environments. There is zero appeal
to many managers of developers being able to make repositories, and
there can be substantial pushback to features like this. To many
managers the features of DVCSs that you or I (or other with-it
developers) like are negative selling points, because they interpret
those as leading to lack of control and lack of visibility.

Sooner or later I'll succeed in getting a client organization
interested, and interested for the right reasons. But it hasn't happened
yet.

AHS

1. History is super-important in these organizations. It is how you
locate scapegoats.

[toc] | [prev] | [next] | [standalone]

#10620

Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
> Let me put it this way, and maybe this helps to make my point: "they
> make creating new repositories much easier", as you mentioned above, is
> _not_ a selling point in many client environments. There is zero appeal
> to many managers of developers being able to make repositories, and
> there can be substantial pushback to features like this. To many
> managers the features of DVCSs that you or I (or other with-it
> developers) like are negative selling points, because they interpret
> those as leading to lack of control and lack of visibility.

I'm putting in a word for the managers: 

The longer you keep your changes local (even if "locally commited"), the
higher is the risk of a conflict with other devels' changesets.

I can imagine managers to be more afraid of longer sync-intervals,
resulting from the DVCS-philosophy, than of not seeing all devels' 
interims work.

> Sooner or later I'll succeed in getting a client organization
> interested, and interested for the right reasons. But it hasn't
> happened yet.

It would have to be a client whose devels are working remote, and
where the benefits of piling up some work before a sync outweighs 
the higher risk of conflicts happening.

> 1. History is super-important in these organizations. It is how you
> locate scapegoats.

I do understand this motivation. The "scapegoat" is typically the one 
who is in the best position to fix a problem, so identifying him without
having to ask everyone is worth as much time as by what the scapegoat
will be able to fix it more efficiently than anyone else on the project.

[toc] | [prev] | [next] | [standalone]

#10624

On 2011-12-09 13:51, Andreas Leitgeb wrote:
> Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
>> Let me put it this way, and maybe this helps to make my point: "they
>> make creating new repositories much easier", as you mentioned above, is
>> _not_ a selling point in many client environments. There is zero appeal
>> to many managers of developers being able to make repositories, and
>> there can be substantial pushback to features like this. To many
>> managers the features of DVCSs that you or I (or other with-it
>> developers) like are negative selling points, because they interpret
>> those as leading to lack of control and lack of visibility.
> 
> I'm putting in a word for the managers: 
> 
> The longer you keep your changes local (even if "locally commited"), the
> higher is the risk of a conflict with other devels' changesets.

Have you thought about how "devel" sounds to a native English speaker? I
wouldn't use that abbrev.

[toc] | [prev] | [next] | [standalone]

#10634

On Fri, 09 Dec 2011 17:26:27 +0100, Lars Enderin wrote:

> On 2011-12-09 13:51, Andreas Leitgeb wrote:
>> Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
>>> Let me put it this way, and maybe this helps to make my point: "they
>>> make creating new repositories much easier", as you mentioned above,
>>> is _not_ a selling point in many client environments. There is zero
>>> appeal to many managers of developers being able to make repositories,
>>> and there can be substantial pushback to features like this. To many
>>> managers the features of DVCSs that you or I (or other with-it
>>> developers) like are negative selling points, because they interpret
>>> those as leading to lack of control and lack of visibility.
>> 
>> I'm putting in a word for the managers:
>> 
>> The longer you keep your changes local (even if "locally commited"),
>> the higher is the risk of a conflict with other devels' changesets.
> 
> Have you thought about how "devel" sounds to a native English speaker? I
> wouldn't use that abbrev.

That is a non-issue. The spelling makes the meaning clear.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#10644

Lars Enderin <lars.enderin@telia.com> wrote:
> On 2011-12-09 13:51, Andreas Leitgeb wrote:
>> Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:
>>> Let me put it this way, and maybe this helps to make my point: "they
>>> make creating new repositories much easier", as you mentioned above, is
>>> _not_ a selling point in many client environments. There is zero appeal
>>> to many managers of developers being able to make repositories, and
>>> there can be substantial pushback to features like this. To many
>>> managers the features of DVCSs that you or I (or other with-it
>>> developers) like are negative selling points, because they interpret
>>> those as leading to lack of control and lack of visibility.
>> I'm putting in a word for the managers: 
>> The longer you keep your changes local (even if "locally commited"), the
>> higher is the risk of a conflict with other devels' changesets.
> Have you thought about how "devel" sounds to a native English speaker? I
> wouldn't use that abbrev.

If you're referring to "devil", then I think it is not all that similar.
(not even phonetically).   If you mean something else, then please let me
know. (email ok, if you prefer)

PS: anything to say about pros and cons of DVCS, too?

[toc] | [prev] | [next] | [standalone]

#10650

On Fri, 9 Dec 2011, Andreas Leitgeb wrote:

> I can imagine managers to be more afraid of longer sync-intervals, 
> resulting from the DVCS-philosophy, than of not seeing all devels' 
> interims work.

The DVCS philosophy does not result in longer intervals between sharing 
work with your colleagues (what i assume you mean by "sync-intervals").

Both centralised and distributed VCS makes it easy to share work with your 
colleagues. You can do it as often or as seldom as you choose, or your 
process dictates. The choice of centralised or distributed VCS has *no* 
bearing on it.

I have come across this belief before. I honestly don't know where people 
get it from.

>> Sooner or later I'll succeed in getting a client organization 
>> interested, and interested for the right reasons. But it hasn't 
>> happened yet.
>
> It would have to be a client whose devels are working remote, and where 
> the benefits of piling up some work before a sync outweighs the higher 
> risk of conflicts happening.

No, as i explained, DVCS has benefits even in a conventionally-organised 
team.

>> 1. History is super-important in these organizations. It is how you
>> locate scapegoats.
>
> I do understand this motivation. The "scapegoat" is typically the one 
> who is in the best position to fix a problem, so identifying him without 
> having to ask everyone is worth as much time as by what the scapegoat 
> will be able to fix it more efficiently than anyone else on the project.

DVCS is capable of recording history just as precisely as centralised VCS. 
Indeed, because you can have multiple local commits in between pushes, it 
can record *more* details about history.

DVCSs also give you tools to erase and rewrite history, but it is your 
choice whether you use them or not. If you care about history, don't use 
them.

tom

-- 
Work alone does not suffice: the efforts must be intelligent. -- Charles
B. Rogers

[toc] | [prev] | [next] | [standalone]

#10652

Tom Anderson <twic@urchin.earth.li> wrote:
> On Fri, 9 Dec 2011, Andreas Leitgeb wrote:
>> I can imagine managers to be more afraid of longer sync-intervals, 
>> resulting from the DVCS-philosophy, than of not seeing all devels' 
>> interims work.
> The DVCS philosophy does not result in longer intervals between sharing 
> work with your colleagues (what i assume you mean by "sync-intervals").

If all changes committed to local "clone" get automaticall sync'ed
to some master repository, then there's little change from status quo.

If not, then obviously the interval between syncs is longer than that 
between commits.

> Both centralised and distributed VCS makes it easy to share work with your 
> colleagues.

I haven't yet *worked* with git/hg/...
I've however used a dvcs to retrieve the source of some open-source
project that I wanted a newer version of than packaged with my OS
distribution and I've skimmed over a couple of howto's telling how
to use the new DVCS, often with guides for CVS'lers about the replace-
ments for each of their previous typical command lines.
Guess what: the new commands were constantly more complicated.
Instead of typing one command to see the locally modified files, and
available changes from the repo for the current subtree of the project,
one has to sync first, then issue one command for this and another for
that and yet another...

If some external person were to talk me into this, I might also
tell them that I'd change to TFS, just to make *him* stfu on this.

You won't get anyone off CVS who hasn't yet fallen victim to CVS's
limitations, and less have, than you might think.

Maybe it's like you won't get a Joe Doe user off Windows, unless he's
just lost a week of work to viruses... And strangely enough, some haven't.

> I have come across this belief before. I honestly don't know where people 
> get it from.

Typically, they read it between the lines of what dvcs-advocates write.

> No, as i explained, DVCS has benefits even in a conventionally-organised 
> team.

I've read some (in this thread, and before), but didn't so far 
find any that I'd buy as relevant for my projects at work. Arved(?)'s
remarks (about clients refusing dvcs) seemed to me, as if his clients
happened to share my version of reality.

>> I do understand this motivation. The "scapegoat" is typically the one 
>> who is in the best position to fix a problem, so identifying him without 
>> having to ask everyone is worth as much time as by what the scapegoat 
>> will be able to fix it more efficiently than anyone else on the project.
> DVCS is capable of recording history just as precisely as ...

Oh, sure, never doubted that.  The comment I answered appeared to 
ridicule management's desire to find "scapegoats" as primary drive
behind (over?)valueing vcs-history. As if they were always just trying
to find someone to sack.

[toc] | [prev] | [next] | [standalone]

#10651

[Multipart message — attachments visible in raw view] — view raw

On Fri, 9 Dec 2011, Arved Sandstrom wrote:

> On 11-12-08 12:04 PM, Tom Anderson wrote:
>> On Wed, 7 Dec 2011, Arved Sandstrom wrote:
>>
>>> On 11-12-07 07:57 PM, Arne Vajhøj wrote:
>>>
>>>> The distributed part is great for code that is being worked on by 
>>>> completely independent organizations (read: large open source 
>>>> projects).
>>>>
>>>> But most people do not really have that need.
>>>
>>> I agree that there are plenty of scenarios that benefit from a 
>>> distributed VCS. But a whole bunch don't.
>>
>> It's true that a great many projects don't need the anarchic 
>> fully-distributed mode of operation that DVCS allows.
>>
>> But the thing that DVCS gives you that is invaluable to everyone, 
>> everywhere, is local commits.
>
> Tom, no need to sell _me_, I am sold already. :-)

Ah, sorry. When you wrote:

  I agree that there are plenty of scenarios that benefit from a
  distributed VCS. But a whole bunch don't.

I assumed that meant that you didn't think DVCS had universal benefits.

> That's why I have tried three times in as many years to introduce a DVCS 
> in a real work environment. Each time it's been a SVN shop (which is 
> part of the problem, they've already got SVN).
>
> I'll tell you why it's failed:
>
> 1. It's (legitimately) hard to convince a client that a centralized DVCS 
> model is significantly better than a SVN setup. It has to be 
> _significantly_ better because they are facing a migration of history 
> (History is super-important in these organizations. It is how you locate 
> scapegoats.)

There are conversion tools which will import repositories, with history, 
from other VCSs into various modern DVCSs; we used cvs2git to convert some 
of our projects from CVS to Git, and it worked pretty well. There was a 
bit of manual faffing about, though - i think the conversion took about a 
day to get right. I believe the conversion from Subversion to Hg/Git is 
much smoother than from CVS, because Subversion at least has atomic 
commits.

Nonetheless, i recognise that conversion is not necesssarily 
straightforward. I've seen questions on the Mercurial mailing list about 
people having real trouble with it - although of course that's 
self-selecting, as the people for whom it goes smoothly don't post!

> 2. Very few arguments that have to do with benefits for _developers_ are 
> important. You don't have to convince developers, you have to convince 
> managers.
>
> 2. Only the developers amongst the client personnel understand your 
> "local commits" argument, or the other one (better branching/merging 
> than SVN). Problem is, very few of the managers get it, and _they_ are 
> the ones that need to be convinced.
>
> I've encountered my share of client managers that actually don't see 
> your description of local commits as being a good thing, unlike you or 
> me or most developers. To them that all sounds like coders wasting time 
> at best, and unsupervised work at worst.

Interesting and depressing. Why on earth are people who don't understand 
programming making decisions about programming tools? These sound like 
very sick organisations. Plenty of those around, of course!

> In fact I'm satisfied that hg/git are always at least as good as svn, 
> and usually better.
>
> It's simply that I have yet to encounter a team environment where the 
> managers bought this.

This is just baffling to me. These people make software, right? So it's in 
their interest to have the best tools for making software? This is like 
shipwrights preferring to stick with forge welding rather than adopting 
arc welders.

But, yes, it happens. On my last big external project, we used CVS; we 
pointed out that CVS wasn't very good, and suggested moving to Git/Hg, and 
the client came back and suggested moving to their corporate standard, 
which was Team Foundation Server. We quickly backtracked and said that CVS 
was just fine. Ugh.

tom

-- 
Work alone does not suffice: the efforts must be intelligent. -- Charles
B. Rogers

[toc] | [prev] | [next] | [standalone]

#10661

Arved Sandstrom <asandstrom3minus1@eastlink.ca> writes:

> 1. History is super-important in these organizations. It is how you
> locate scapegoats.

History is an important working tool for me.  It's the first thing I
look at when I want to know why a piece of code is written the way it is
rather than the way I think it should be, or the way I originally wrote
it.  Fairly often there turns out to be a reason, usually tied to a
customer request.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web