I think the best being version control.
One case in point was my last place of employment, where I was first stationed at a PC that my manager knew was not on the backup power system for the building. Although I expressed a concern about this, I was just told "...backup your files to the server...".
Version control isn't just a backup tool or a "keep track" tool. It also serves to:
a) provide the developer with a means to go back to a previous version without having to "rip" out new code, if a decision is made to remove a previously approved application enhancement.
and
b) provide other developers with a means of getting to your code with the least impedance in case of your absence, i.e.-not having to get admin access to your drive, hunt it down, knowing they have the latest code, etc.
Given, you have to get the developer to make a habit of checking in and out code. And, it's always smart to have a lead check new mods into the project as not to contaminate existing working code.
But when it has been done, I've found that it saves a lot of time and headaches for me as a developer and the others with whom I worked.
Discussion on:
View:
Show:
too much to cope with the lack.
The essence of good business code is readability. My contention is if you have to comment your code so it can be understood, you wrote it wrong.
Comments as to why the best or most obvious solution has not been chosen are useful. These you rarley see, what you do get is utterly useless and distracting swathes of commenting, which essentially translate your chosen language into english like.
//Loop through the List of invoices
While Index Invoicelist.Count Do ....
F'ing useless. The proliferation of comments obscures the code, and worse they get out of date, or possibly cut and pasted without revision. A misleading comment is as bad as a misleading object name.
The comment about coders hoarding and obfuscating is well taken though, counter-productive. The first person it's going to confuse is likely to be them.
Source control is an absolute boon, and the best invention since long variable names.
The essence of good business code is readability. My contention is if you have to comment your code so it can be understood, you wrote it wrong.
Comments as to why the best or most obvious solution has not been chosen are useful. These you rarley see, what you do get is utterly useless and distracting swathes of commenting, which essentially translate your chosen language into english like.
//Loop through the List of invoices
While Index Invoicelist.Count Do ....
F'ing useless. The proliferation of comments obscures the code, and worse they get out of date, or possibly cut and pasted without revision. A misleading comment is as bad as a misleading object name.
The comment about coders hoarding and obfuscating is well taken though, counter-productive. The first person it's going to confuse is likely to be them.
Source control is an absolute boon, and the best invention since long variable names.
There are times when a lot of comments are a good thing.
such as when the code will be used in a classroom or workshop to teach programming or the language being used.
but other than that, a comment before the beginning of a function stating the purpose of the function is the only real commenting needed, even then, only when it is not an obvious function.
what comment needed for a function named: write_file
none, pretty obvious what it does.
such as when the code will be used in a classroom or workshop to teach programming or the language being used.
but other than that, a comment before the beginning of a function stating the purpose of the function is the only real commenting needed, even then, only when it is not an obvious function.
what comment needed for a function named: write_file
none, pretty obvious what it does.
recommend comment everything.
That was for the days of short variable names.
Last place it was the standard, reams of source and a comment between every line. I got told off or not sticking to it, my habit of ignoring stupid people was noticed.
! Loop from 1 to 4
Do loop =1 , 4
**** off, not doing it, you end up with this
!Loop From 1 to 4
Do Loop = 1 ,5
????
That was for the days of short variable names.
Last place it was the standard, reams of source and a comment between every line. I got told off or not sticking to it, my habit of ignoring stupid people was noticed.
! Loop from 1 to 4
Do loop =1 , 4
**** off, not doing it, you end up with this
!Loop From 1 to 4
Do Loop = 1 ,5
????
I think a little perspective needs to be added to the subject of code comments. I agree that well chosen variable and object names eliminate the need for a lot of comments, however, how many times have you looked at some code that someone else wrote, and even though you knew what it was doing, had no idea how it was doing it? I have been coding for over 10 years and it still happens - what is blindingly obvious to one is not necessarily so to someone else!
In my role I often work with more junior developers, where a team is often crossing ove rthe work of others while adding fucntions or enhancements to a relatively mature product. We always take the approach that in areas of basic function a simple description of the overall operation is fine, but for areas where the code is complex, or just different to what has been used elsewhere for whatever reason, more (sometimes much more) explanation is needed. Just by using a little common sense you can make life far, far easier for not just juniors but all team members without making the code hard to read. The cost of an experienced developer taking longer to read the code (not to mention write the comments) is easily offset by all others being able to easily see what it is actually doing.
Oh, and if one of my juniors cut and pastes code or changes something within code without revisiting and editing the comments as needed, I jump on them harder than if they didn't get the code to work in the first place, for the very same reasons as above - the other people on the project (often the person helping the junior or debugging the code) won't be able to understand what they are trying to do!
In my role I often work with more junior developers, where a team is often crossing ove rthe work of others while adding fucntions or enhancements to a relatively mature product. We always take the approach that in areas of basic function a simple description of the overall operation is fine, but for areas where the code is complex, or just different to what has been used elsewhere for whatever reason, more (sometimes much more) explanation is needed. Just by using a little common sense you can make life far, far easier for not just juniors but all team members without making the code hard to read. The cost of an experienced developer taking longer to read the code (not to mention write the comments) is easily offset by all others being able to easily see what it is actually doing.
Oh, and if one of my juniors cut and pastes code or changes something within code without revisiting and editing the comments as needed, I jump on them harder than if they didn't get the code to work in the first place, for the very same reasons as above - the other people on the project (often the person helping the junior or debugging the code) won't be able to understand what they are trying to do!
as long as you aren't one of them annoying bleeders who litters them all over the code. Just don't follow what sems to be standard practice and substitute reams of comments for good code.
Talking of standard practice, that is as valuable as comments. If your code base is structured the same way throughout it can save an enormous amount of effort for an other developer, or even your good self in six months time. If the code is well written understanding it won't be a problem, finding it can be though.
There is no 'right' way of going about this, it's just sticking to the same methods as long as they aren't the wrong ways.
I said somewhere else in relation to comments
Why, then how never ever what.
If they don't know
While Condition Do
is the start of loop keep HR out of the recruitment process.
Talking of standard practice, that is as valuable as comments. If your code base is structured the same way throughout it can save an enormous amount of effort for an other developer, or even your good self in six months time. If the code is well written understanding it won't be a problem, finding it can be though.
There is no 'right' way of going about this, it's just sticking to the same methods as long as they aren't the wrong ways.
I said somewhere else in relation to comments
Why, then how never ever what.
If they don't know
While Condition Do
is the start of loop keep HR out of the recruitment process.
One practice to teach to your junior programmers is to never cut and paste; create a common subroutine or method instead.
Well written code is much more than variable and object names; the key is decomposing large methods into small pieces.
A key tenet of Exterem Programming is that a comment is a sign that code needs to be refactored. In practice, this means to take the gist of the comment and change it into a method name and move the commented code into the method. The immediate benefit is that the code reads like prose and its appearance becomes that of an intent (the method name) followed a list of steps to accomplish the intent.
A second, though longer term, advantage is that once one adopts this approach, one's code writing quality also improves as one is writing code in a style closer to one's though processes. The code writing process becomes a top-down effort where first one defines the top level steps and then writes the details to acomplish these steps.
As a reformed commenter, I feel much like a reformed smoker and tend to evangelize. My peers often comlimented my on my comments and code layout. It was a revelation when I realized that the effort I was putting into commenting was time I was not spending on the code and I was merely masking my less clear coding style. I now find that my coding style consists of more methods of shorter length, and that the methods are now much more organized in a logical top-down approach.
There are a few times where comments may be necessary, typically where using libraries or code that one cannot modify. In this case, one may be forced to write comments as opposed to renaming a poor method name or to describe some unusual processing or error handling.
Writing comments to clarify code is the easy way out. One does not need to think. Often, within the same amount of time, one can improve the readability of the code, rather than just tacking on some comments to describe the code in the way it shoudl be written.
A key tenet of Exterem Programming is that a comment is a sign that code needs to be refactored. In practice, this means to take the gist of the comment and change it into a method name and move the commented code into the method. The immediate benefit is that the code reads like prose and its appearance becomes that of an intent (the method name) followed a list of steps to accomplish the intent.
A second, though longer term, advantage is that once one adopts this approach, one's code writing quality also improves as one is writing code in a style closer to one's though processes. The code writing process becomes a top-down effort where first one defines the top level steps and then writes the details to acomplish these steps.
As a reformed commenter, I feel much like a reformed smoker and tend to evangelize. My peers often comlimented my on my comments and code layout. It was a revelation when I realized that the effort I was putting into commenting was time I was not spending on the code and I was merely masking my less clear coding style. I now find that my coding style consists of more methods of shorter length, and that the methods are now much more organized in a logical top-down approach.
There are a few times where comments may be necessary, typically where using libraries or code that one cannot modify. In this case, one may be forced to write comments as opposed to renaming a poor method name or to describe some unusual processing or error handling.
Writing comments to clarify code is the easy way out. One does not need to think. Often, within the same amount of time, one can improve the readability of the code, rather than just tacking on some comments to describe the code in the way it shoudl be written.
I'll quote you, sounds much more educational, than WTF is this, in a despairing tone of voice.
If I find someone who won't listen I lways make sure they get their code back in about six months. It's amazing how many times you hear a cry of "Who wrote this crap?", followed by a nervous glance round and total silence.
Was me once too, good coding practice is something you learn from working with bad code, especially your own.
Didn't learn it from extreme programming, though top down is pretty much the way I work.
If I find someone who won't listen I lways make sure they get their code back in about six months. It's amazing how many times you hear a cry of "Who wrote this crap?", followed by a nervous glance round and total silence.
Was me once too, good coding practice is something you learn from working with bad code, especially your own.
Didn't learn it from extreme programming, though top down is pretty much the way I work.
Testing, Testing, and more testing ( aka Location, Location, Location).
Junior programmers are not usually mature enough to understand the impact of their small module/package. Testing extensively removes the possibility of test case failing in 1 out of 30~40 test scenarios.
PS - I usually sit down with the programmers before he start the design phase and think of all of the test cases where it might fail, and to trap those error conditions.
Ashish
Junior programmers are not usually mature enough to understand the impact of their small module/package. Testing extensively removes the possibility of test case failing in 1 out of 30~40 test scenarios.
PS - I usually sit down with the programmers before he start the design phase and think of all of the test cases where it might fail, and to trap those error conditions.
Ashish
As a software engineer, active and observant in commercial and open-source development, I've thought source code control, information sharing and most of the practices described in this article were common engineering practices!
I'm surprised that many of these practices are seen as novel, when every SourceForge (open source) project, relies on version control for instance. Globally, these practices _are_ software engineering...
The scariest thing about this is that if the entire US software engineering community doesn't start practicing as a full-fledged engineering discipline, we will further allow other nations to eat away at our jobs.
We cannot simply provide functioning code, but it needs to be effectively, efficiently produced and it needs to be done in a way that's reproducible over and over with incremental improvements each time.
I'm surprised that many of these practices are seen as novel, when every SourceForge (open source) project, relies on version control for instance. Globally, these practices _are_ software engineering...
The scariest thing about this is that if the entire US software engineering community doesn't start practicing as a full-fledged engineering discipline, we will further allow other nations to eat away at our jobs.
We cannot simply provide functioning code, but it needs to be effectively, efficiently produced and it needs to be done in a way that's reproducible over and over with incremental improvements each time.
It's surprising what developers sometimes aren't doing. One of the hiring criteria for my current job was some familiarity with version control using Subversion. The fact that some shops don't even using version control software just boggles my mind.
That one character variable names aren't a time saver. Source control, pie in the sky futuristic nonsense, never happen.
you mean it doesn't help to use:
int c, i, x, j, k, w;
for a variable declaration?
are you saying that:
int count, incrementer, user_input, just_in_case, kill_joy, whatever;
is a better declaration?
int c, i, x, j, k, w;
for a variable declaration?
are you saying that:
int count, incrementer, user_input, just_in_case, kill_joy, whatever;
is a better declaration?
you see
whatever := somethingveryspecific;
We should simplify the process and just no have variable declarations, or just do them on the fly as you need them. Think of all the time and effort that would save.
whatever := somethingveryspecific;
We should simplify the process and just no have variable declarations, or just do them on the fly as you need them. Think of all the time and effort that would save.
php that is what happens.
it can be really convienient, but it can also be really dangerous. php allows for int variable to be cast as a string by the code.
so if you are trying to get the numerical value of a string, you have to actually specify it.
with most languages, putting a string into an integer variable will give you the numerical value.
a few other got yas with dynamic variable declaration / casting.
the required declaration, while problematical in knowing what you need sometimes, also are tighter when coding, making casting errors harder to miss.
it can be really convienient, but it can also be really dangerous. php allows for int variable to be cast as a string by the code.
so if you are trying to get the numerical value of a string, you have to actually specify it.
with most languages, putting a string into an integer variable will give you the numerical value.
a few other got yas with dynamic variable declaration / casting.
the required declaration, while problematical in knowing what you need sometimes, also are tighter when coding, making casting errors harder to miss.
Single pass compilation.
Optimisation strategies.
and being able to find where the damn thing is declared.
PHP is better than many scripting languages, but it's still a scripting language.
Optimisation strategies.
and being able to find where the damn thing is declared.
PHP is better than many scripting languages, but it's still a scripting language.
Better than what scripting languages? You state that PHP is better than "many scripting languages", but I can't think of one right now that is worse, aside from perhaps Javascript and anything MS proprietary.
Maybe the problem is that I don't know what you mean by "better".
Maybe the problem is that I don't know what you mean by "better".
huh?
while I do think php is a good language, when used for it's designed purpose.
( Personal Home Page )
why is it better than using something like perl for a lot of string work?
perl does have the best collection of string functions.
I would never recommend using php for a bash script. ( even though it is possible )
yet perl is often used for them.
while I do think php is a good language, when used for it's designed purpose.
( Personal Home Page )
why is it better than using something like perl for a lot of string work?
perl does have the best collection of string functions.
I would never recommend using php for a bash script. ( even though it is possible )
yet perl is often used for them.
There again so is nailing your nuts to a short legged coffeee table.
I am scripted languages of any kind most least enthusiastic fan, as far as I'm concerned they were invented for people who could n't be arsed to learn how to do something properly.
I am scripted languages of any kind most least enthusiastic fan, as far as I'm concerned they were invented for people who could n't be arsed to learn how to do something properly.
Writing glue code for shell utilities, unit tests for network protocol agents, and automation code for administrative tasks is never done "properly" in a language that requires precompilation to binary executables. The same goes for things like markup-embedded code, client side dynamic execution, macros, one-shot tasks, system configuration files, interactive execution environments, rapid prototyping, or anything that can be done well in one short procedure.
If you really think scripting is only for people who can't be arsed to do something "right", you lack some essential experience.
If you really think scripting is only for people who can't be arsed to do something "right", you lack some essential experience.
I've glued together more than a few proper bits of 'proper' code with a script myself, mainly in VMS environments.
That's what scripting was designed to do, not to to write an enterprise wide sales order processing system with an access backend. People are actually doing this I remember a thread last year where someone was 'marketing' a solution to a large system based on javascript, over ten thousand lines of it for client side validation! Said it was a good way of achieving the objective. Javascript isn't the best scripting language I've ever seen and I hate client side, but scripting's necessary looseness in terms of variable typing, semantic structures etc makes for ease of use, not best use.
That's what scripting was designed to do, not to to write an enterprise wide sales order processing system with an access backend. People are actually doing this I remember a thread last year where someone was 'marketing' a solution to a large system based on javascript, over ten thousand lines of it for client side validation! Said it was a good way of achieving the objective. Javascript isn't the best scripting language I've ever seen and I hate client side, but scripting's necessary looseness in terms of variable typing, semantic structures etc makes for ease of use, not best use.
scripting has it's place, and full apps ain't where it should be.
using the right tool for the job is part of every industry.
php, for web scripting.
perl for something with all test work
javascript, vbscript, only if you have no reason to ever want to write a script again for that company.. since you should be fired for using either.
using the right tool for the job is part of every industry.
php, for web scripting.
perl for something with all test work
javascript, vbscript, only if you have no reason to ever want to write a script again for that company.. since you should be fired for using either.
This works fine if used correctly. I had developers update code out side of source control and put into production and eventually overwritten and lost forever. I've found the best way was to back up the code. This has never failed me.
One problem that was not brought up was with management that decide that upgrading existing systems with inexperienced developers while their experienced developers cringe at the thought of having to maintain a system developed by an over educated moron with a masters degree who developed systems for themselves and not the inexperienced developers who will use the system. I hate to say how much of my time has been wasted by having to educate other programmers how to use code written by someone trying to prove how special they are with no regards to who will be using it.
One problem that was not brought up was with management that decide that upgrading existing systems with inexperienced developers while their experienced developers cringe at the thought of having to maintain a system developed by an over educated moron with a masters degree who developed systems for themselves and not the inexperienced developers who will use the system. I hate to say how much of my time has been wasted by having to educate other programmers how to use code written by someone trying to prove how special they are with no regards to who will be using it.
If you want to stop the developers from writing code outside of source, simple remove the developer's ability to modify production directly.
In our shop, the only way production can be modified is when the developer triggers the deploy system. The system has three steps that are totally automatic:
1) Check out entire project from source control. If this is successful,
2) The entire project is built. If this is successful,
3) The build is rolled to production and an email is sent to a distribution list (change control, system admin, developer lead, and help desk). The body of the email includes the log of the latest commit.
So, there is no way for a developer to "lose code" because they can't even touch production (they have full access to development machines, though). The scheme also ensures that the committed code will actually build, and the email ensures that everyone who needs to know, knows. So if the help desk starts getting calls, they know the name of the last person to make changes, and (hopefully) can get a sense of what changed.
In our shop, the only way production can be modified is when the developer triggers the deploy system. The system has three steps that are totally automatic:
1) Check out entire project from source control. If this is successful,
2) The entire project is built. If this is successful,
3) The build is rolled to production and an email is sent to a distribution list (change control, system admin, developer lead, and help desk). The body of the email includes the log of the latest commit.
So, there is no way for a developer to "lose code" because they can't even touch production (they have full access to development machines, though). The scheme also ensures that the committed code will actually build, and the email ensures that everyone who needs to know, knows. So if the help desk starts getting calls, they know the name of the last person to make changes, and (hopefully) can get a sense of what changed.
I'm assuming the build includes tests before it's rolled out to production?
Unit Tests, absolutely (I always make the build process include these, so test fails=build fails).
Integration tests are a little harder, but you can use something like cactus + dbunit + HLSQL.
Functional tests happen when the users start using it (sad, but true).
Integration tests are a little harder, but you can use something like cactus + dbunit + HLSQL.
Functional tests happen when the users start using it (sad, but true).
I think some of the ideas in this discussion could be further expanded upon, especially concerning comments, version control, and data validation.
Observations on .Net and Web Services seem to be very specific to a particular team and do not appear to rise to the level of general advice. Team communications is a key issue and deserves a much larger discussion of how to accomplish good communications.
Concerning comments, I would recommend that developers embrace the Extreme Programming approach that a comment is an indicator of code that needs to be refactored; needs to be rewritten for clarity. Rather than trying to explain what unclear code is doing with a comment, clean up the code. We have been far too accepting of obscure code with the explanation "well, at least it works."
Regarding Version Control, it needs to be used far more frequently than at the end of a development effort to roll back to the previous release. I try to enforce a rule that everyone checks in his code before he leaves for the day, and recommend even more frequent check ins. If an approach is simply not working, it makes it much easier to go back and try a different approach if you can just go back and lose only 1 - 2 hours of work. If one has longer time frames, there is increased pressure to continue down the current path. It is also much more difficult to strip out code and adapt it to a new approach than just going back to a clean slate.
Concerning data validation, this needs to be a project decision on when and where to validate data. Data validation is usually needed at all external interfaces, but is not of value on internal methods. Decide when and where data is to be validated.
One are not discussed is testing. This is slowly becoming an accepted development practice, but there is still an underlying belief that testing is done by lower-level employees and it is an embarassment to ask a developer to do testing. Again, see Extreme Programming and Test Driven Design.
There are a lot of newly formalized development practices. Some of these have been done to varying degrees in the past, but the formalization provides for consistency. Read up on the newer practices and give them a try. They will improve your development efforts.
Observations on .Net and Web Services seem to be very specific to a particular team and do not appear to rise to the level of general advice. Team communications is a key issue and deserves a much larger discussion of how to accomplish good communications.
Concerning comments, I would recommend that developers embrace the Extreme Programming approach that a comment is an indicator of code that needs to be refactored; needs to be rewritten for clarity. Rather than trying to explain what unclear code is doing with a comment, clean up the code. We have been far too accepting of obscure code with the explanation "well, at least it works."
Regarding Version Control, it needs to be used far more frequently than at the end of a development effort to roll back to the previous release. I try to enforce a rule that everyone checks in his code before he leaves for the day, and recommend even more frequent check ins. If an approach is simply not working, it makes it much easier to go back and try a different approach if you can just go back and lose only 1 - 2 hours of work. If one has longer time frames, there is increased pressure to continue down the current path. It is also much more difficult to strip out code and adapt it to a new approach than just going back to a clean slate.
Concerning data validation, this needs to be a project decision on when and where to validate data. Data validation is usually needed at all external interfaces, but is not of value on internal methods. Decide when and where data is to be validated.
One are not discussed is testing. This is slowly becoming an accepted development practice, but there is still an underlying belief that testing is done by lower-level employees and it is an embarassment to ask a developer to do testing. Again, see Extreme Programming and Test Driven Design.
There are a lot of newly formalized development practices. Some of these have been done to varying degrees in the past, but the formalization provides for consistency. Read up on the newer practices and give them a try. They will improve your development efforts.
re the check-in for version control:
use a scheduled task to automatically check any altered source files in if the file has not been touched for 15 minutes.
then it's checked-in to the version control without the developer needing to do so.
in an emergency ( fire / bomb threat ) then it's all checked in so the data / changes aren't lost.
cause there is no way I would stop to check sources in before leaving in a case like that.
use a scheduled task to automatically check any altered source files in if the file has not been touched for 15 minutes.
then it's checked-in to the version control without the developer needing to do so.
in an emergency ( fire / bomb threat ) then it's all checked in so the data / changes aren't lost.
cause there is no way I would stop to check sources in before leaving in a case like that.
One of the rules I enforce on my development team is that no one check-in software until he has tested it and verifies it works.
If an automated check-in is used, it is highly likely that most check-ins will contain software that does not even compile, much less work. I would expect that 15 minutes after the first developer starts work, the automated check-in would kick in and everyone who follows would get a broken baseline and not be able to do any work.
The save points for the software must be based on the work flow and not merely time. I want my roll back points to always be working software, so I have to accept the loss of work that would occur between roll back points. Thanks for a good, thought provoking idea!
If an automated check-in is used, it is highly likely that most check-ins will contain software that does not even compile, much less work. I would expect that 15 minutes after the first developer starts work, the automated check-in would kick in and everyone who follows would get a broken baseline and not be able to do any work.
The save points for the software must be based on the work flow and not merely time. I want my roll back points to always be working software, so I have to accept the loss of work that would occur between roll back points. Thanks for a good, thought provoking idea!
check in and commits are different.
checking it into the cvs server doesn't commit the changes to the tree.
this allows for multiple testing from several different people before commiting it into the repository.
checking it into the cvs server doesn't commit the changes to the tree.
this allows for multiple testing from several different people before commiting it into the repository.
some of us are cursed with Visual Source safe. Does n't even interface well to ms products.
Never been mad keen on auto check in, it will work but yiou have to be very disciplined about checking out as well. A lot of people aren't and some poor pratt spends three quarters of an hour, trying to figure out why the last version doesn't work anymore.
Even worse problems with common library units or base classes in a team environment.
Never been mad keen on auto check in, it will work but yiou have to be very disciplined about checking out as well. A lot of people aren't and some poor pratt spends three quarters of an hour, trying to figure out why the last version doesn't work anymore.
Even worse problems with common library units or base classes in a team environment.
subversion.
( newest thing in open source shared version control )
I do beleive in using verson control for most projects. specially if it involves a lot of one-off code and only base libs for the language.
but if the app is only using established libs, then you are really only creating a user interface, and version control isn't a big priority.
automatic checkin and automatic commits are drastically different.
( using checkin as add to repository, not replace in repository )
commiting says ( to me ) that you have tested the code and it is functional. adding means you have it ready or are backing up changes for procedure / policy or testing by others.
( gotta love the stages that cvs allows don't ya.. unstable adds to stable, tested commits )
( newest thing in open source shared version control )
I do beleive in using verson control for most projects. specially if it involves a lot of one-off code and only base libs for the language.
but if the app is only using established libs, then you are really only creating a user interface, and version control isn't a big priority.
automatic checkin and automatic commits are drastically different.
( using checkin as add to repository, not replace in repository )
commiting says ( to me ) that you have tested the code and it is functional. adding means you have it ready or are backing up changes for procedure / policy or testing by others.
( gotta love the stages that cvs allows don't ya.. unstable adds to stable, tested commits )
Thanks for the info! I've never worked with CVS or any other system where the individual check-in and the team commit were separate.
With your explanation, I agree it would make a lot of sense to have a background save of working data.
I'll go out and check out CVS directly, but sadly most of my work is at customer sites and you gotta use what they give you. Thanks again for the tip.
With your explanation, I agree it would make a lot of sense to have a background save of working data.
I'll go out and check out CVS directly, but sadly most of my work is at customer sites and you gotta use what they give you. Thanks again for the tip.
of source branching.
only the server admin ( team leader ) can merge the developers "branch" with the main trunk.
this is a tightly secured repository, to protect the stable core of an app.
it does have serious drawbacks, but it has some benefits.
cvs itself is far more robust than a lot of people realise, mainly through lack of opportunity to test it.
a simple way to see how well it can work is sourceforge, they use cvs to control the sources for the projects on thier system.
( thier entire site is a team development tool for source control, the service is available, on a per developer license from VAsoft, last time I checked, it was in the area of 10 grand us per developer.
or 500 grand us for unlimited developers. )
only the server admin ( team leader
this is a tightly secured repository, to protect the stable core of an app.
it does have serious drawbacks, but it has some benefits.
cvs itself is far more robust than a lot of people realise, mainly through lack of opportunity to test it.
a simple way to see how well it can work is sourceforge, they use cvs to control the sources for the projects on thier system.
( thier entire site is a team development tool for source control, the service is available, on a per developer license from VAsoft, last time I checked, it was in the area of 10 grand us per developer.
or 500 grand us for unlimited developers. )
You missed "Failure To Design". As a DBA/Developer it never fails to amaze me how many issues could be anticipated and handled if the developer had just taken a few hours to think through what they were doing and design the solution properly. Developers routinely paint themselves into corners and expect the database code to lift them out of it.
Being a programmer myself..i know what it means to code without design...i have made that mistake myself and it has costed lot of money...devlopers SHOULD analyze requirement, define and design the solution before coding....(i know it is difficult to do in small shops)
I think that if the programmer is designing tables or adding fields then the architect is not doing his/her job. The database should be all designed before the programmer starts coding. The architect has already designed it based on the requirements and the prototype. The programmer should not need to know everything about the system. The programmer only needs to know about the one piece of code that he/she is designing for. That includes the variables coming in and the variables that should be coming out. Everything in the black box that the developer is creating they are free to do whatever they want. If not the integration of all the code is a nightmare and is fraught with bugs and recoding.
I've made a carreer out of fighting my way out of corners others had painted me into, Building ladders to escape pitfalls etc. The biggest killer of good design was RAD or QAD as it should be known. Due to business pressure it went from what was intended to be a reactive/iterative design methodology to a designer handbag, with three quarters of the content of the office jumbled up insde it.
I thought I was the only one left who felt this way!
Sure, back in the day we did RAD (or FAD), but it was called "Quick & Dirty", and they were usually Reports or Systems that the company needed NOW, not 6 months from now. Invariably these "One-Time"(?) routines found their way into Production, but even then we scheduled them for review / redesign / rewrite. Nowadays there's virtually no concept of ROI on Systems Development costs, and RAD & FAD are proudly displayed on resumes and job postings under the category: "If you can't fix it, feature it". Systems are thrown together with the assumption that they will be replaced in 1-2 years when we chase after whatever new technology the Trade magazines tell us we MUST have (depending on their largest advertisers).
Sure, back in the day we did RAD (or FAD), but it was called "Quick & Dirty", and they were usually Reports or Systems that the company needed NOW, not 6 months from now. Invariably these "One-Time"(?) routines found their way into Production, but even then we scheduled them for review / redesign / rewrite. Nowadays there's virtually no concept of ROI on Systems Development costs, and RAD & FAD are proudly displayed on resumes and job postings under the category: "If you can't fix it, feature it". Systems are thrown together with the assumption that they will be replaced in 1-2 years when we chase after whatever new technology the Trade magazines tell us we MUST have (depending on their largest advertisers).
Having the framework alone will not get you the compilers, you still need to download and install the SDK. Once installed, you can use your favorite code editor to write the code.
For beginning C# programmers, the author of "Programming in the Key of C#" provides a notepad like editor with hooks that tie into the C# compiler.
That said, I still can't imagine developing any significant amount of code outside of an good IDE.
For beginning C# programmers, the author of "Programming in the Key of C#" provides a notepad like editor with hooks that tie into the C# compiler.
That said, I still can't imagine developing any significant amount of code outside of an good IDE.
Communication is a key to development, but it needs to go beyond the development team and include the user. Developers may know how to code and how to get from point B to point C, but may not always be aware of how the finish product will be used. Testing has to include the user.
The best IDE that I've seen so far is the Bourne again shell with all the usual utilities and programming tools (Vim, gcc/perl/ruby/whatever, gdb, diff, wc, subversion, ls, cat, >, >>, |, et cetera).
bash is a command line interface / interpreter, not an integrated development environment as most people see them.
it isn't specialised as a development tool.
( like kdevelop, QT, Glade, IDLE, tkinter are* )
what you are reffering to is the geek factor of linux / irix / *bsd / unix being programming environment(s) in and of themselves.
* emacs is not specialised, not any more it has become generalised like bash is.
it isn't specialised as a development tool.
( like kdevelop, QT, Glade, IDLE, tkinter are* )
what you are reffering to is the geek factor of linux / irix / *bsd / unix being programming environment(s) in and of themselves.
* emacs is not specialised, not any more it has become generalised like bash is.
not quite there.
( no kernel for it. )
but it's as bad as vi(m) for sucking lemons interface design.
as good as vi(m) for text processing.
both are as confusing as they possibly can be to use. ( unless you have had 16 years to study them ... each )
joe is the best cli editor.
( no kernel for it. )
but it's as bad as vi(m) for sucking lemons interface design.
as good as vi(m) for text processing.
both are as confusing as they possibly can be to use. ( unless you have had 16 years to study them ... each )
joe is the best cli editor.
It has a kernel. It's just missing its own hardware abstraction. That's why it has to run on top of another OS.
Vim's interface is awesome. I don't know what's wrong with you. It's the most efficient way available to edit text, and I never have to remove my hands from home row position when using it.
Sure, Vim has a steep learning curve, but so does Linux. Are you going to start saying we should use DOS instead of Linux since you can learn the whole thing in an afternoon?
Vim's interface is awesome. I don't know what's wrong with you. It's the most efficient way available to edit text, and I never have to remove my hands from home row position when using it.
Sure, Vim has a steep learning curve, but so does Linux. Are you going to start saying we should use DOS instead of Linux since you can learn the whole thing in an afternoon?
any cli app that has a learning curve requiring over 20 minutes is way to complex for the interface.
cli apps should have minimal complexity in interface design.
I remember writing a dos based editor when learning programming, much easier to use than vi(m) or emacs.
if the manual for a cli application is over 1 page long, it's to complex, simplify the app.
how long is the manual for less?
how long for vi(m)?
how long for joe?
we'll leave the 3 mb manual for emacs alone.
cli apps should have minimal complexity in interface design.
I remember writing a dos based editor when learning programming, much easier to use than vi(m) or emacs.
if the manual for a cli application is over 1 page long, it's to complex, simplify the app.
how long is the manual for less?
how long for vi(m)?
how long for joe?
we'll leave the 3 mb manual for emacs alone.
It's not about the size of the manual: it's about what you can do with the application.
It only takes as long to learn how to use vim as well as joe as it takes to learn joe. It only takes as long to learn how to use vim as well as ed as it takes to learn ed. Spend three minutes playing with vim, and you can edit documents. Read a few short sentences about it, and you've got a firm grasp of how to effectively edit config files. Learn the commans for less, and you can move around in vim as easily as in less.
With vim, though, you're not just done at that point. If you want to keep learning, you can. Just like comparing Linux with Windows, you're not done when you've figured out how to point and click (or how to type and save, in the case of vim vs. joe). If you want to be more effective, you can.
If you decide you want to keep learning more about what you can do in vim, you'll discover that the point of a highly functional text processor is not simply to be able to edit documents: it's to edit them quickly and efficiently in a way that lesser text editors will not allow.
If you can't get past the point that vim is more than arrow keys and letters, you're lacking imagination, or curiosity, or some other essential characteristic that would allow you to be more effective in a console-based environment.
It only takes as long to learn how to use vim as well as joe as it takes to learn joe. It only takes as long to learn how to use vim as well as ed as it takes to learn ed. Spend three minutes playing with vim, and you can edit documents. Read a few short sentences about it, and you've got a firm grasp of how to effectively edit config files. Learn the commans for less, and you can move around in vim as easily as in less.
With vim, though, you're not just done at that point. If you want to keep learning, you can. Just like comparing Linux with Windows, you're not done when you've figured out how to point and click (or how to type and save, in the case of vim vs. joe). If you want to be more effective, you can.
If you decide you want to keep learning more about what you can do in vim, you'll discover that the point of a highly functional text processor is not simply to be able to edit documents: it's to edit them quickly and efficiently in a way that lesser text editors will not allow.
If you can't get past the point that vim is more than arrow keys and letters, you're lacking imagination, or curiosity, or some other essential characteristic that would allow you to be more effective in a console-based environment.
is the default, required by standards, text EDITOR, it's capabilities and interface are wrong. the requirements of a default config file text editor fall far short of cli text processing.
a small test:
take someone who has only worked with win9x or newer, put them on a linux box with runlevel 3 and only vi(m) as editor. let them edit the config files to get xserver running so they can run in runlevel 5.
they will throw linux box away.
vi(m) is not user friendly to those who will need it to be the most.
vi(m) as required default text editor is why linux is not getting widespread dekstop usage from home users, specially with debian, debian based, slakware, slakware based and lfs type distros, where it is cli until you get an xserver installed, after rebooting into the linux install.
a small test:
take someone who has only worked with win9x or newer, put them on a linux box with runlevel 3 and only vi(m) as editor. let them edit the config files to get xserver running so they can run in runlevel 5.
they will throw linux box away.
vi(m) is not user friendly to those who will need it to be the most.
vi(m) as required default text editor is why linux is not getting widespread dekstop usage from home users, specially with debian, debian based, slakware, slakware based and lfs type distros, where it is cli until you get an xserver installed, after rebooting into the linux install.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
