Slashdot Mirror
How Do You Store Your Previously-Written Code?
Asmor asks: "I'm a novice programmer who is largely self-taught. It's never been too much trouble for me to reinvent the wheel constantly before, but now as my ambitions get loftier I'm finding that I could really benefit from maintaining some oft-used code that can easily be reused. The problem is, I really don't have any experience with this and I'm not really sure how I should organize things, how the code should be stored, how it should be implemented, etc. I think this is what people mean when they talk about libraries and/or APIs, but not really sure. I'm specifically curious about PHP and JavaScript, but advice for other programming languages is also helpful! How do you store and maintain your most frequently used code?"
Whenever I change my main machine, that dir is of course copied to the new one, and included in the backups. Organiwing the libraries by functionality and language would be a nice thing, but I never seem to find the time.
Beware, though: Most employers specify that code written by employees belongs to the company. If you write code as a corporate employee and then leave your employer, you should really think twice before carrying that code with you. If your new boss thinks you are copying code written in a previous job, he would have to throw the book at you.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
I just use 7zip to archive my nighly builds, and email them to myself on my gmail account. I put the comments on the code in the message body. Gmail gives you over 2.5 gigs of storage space, and you can search you message bodies and headers. I can also retrieve my code and projects from anywhere in the world, and don't have to worry about hard drive crashes.
Havoc Video
I think if it would help if he read some background on these types of tools;
http://www.mactech.com/articles/mactech/Vol.14/14
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
If it isn't likely to turn around and be immediately salable, turn around and put it on the web. I've found that doing the extra (minimal) effort of bundling up and organizing the pieces that is necessary for web presentation really does wonders over my previous storage scheme (put it on a cd, then lose the cd).
I've got about a year's worth of random stuff thus rescued now, even as I kick myself over the things I know I wrote but can't find anymore. For what its worth: Here it is
One issue is code re-use.
Code re-use is why you write API's and create your own libraries, so that you don't have to keep re-inventing the wheel.
The other issues are version control, code management, etc. Some ppl here are recommending cvs and other such overkill. If your a novice PHP coder, none of that matters; you probably have a handfull of scripts that weren't written with re-usability in mind, and therefore are minimally reusable (written in a language that doesn't encourage re-usability to boot) so theres no "tool" that will magically let you squeeze the juice of re-usability from stone.
At this point, you biggest concern should be storage for sake of making frequent backups. Personally, I encrypt whatever folder I'm working in (using PGP) and email it to my gmail account every day. That way it's accessible no matter where I am, and pretty secure too.
"Is this just useless, or is it expensive as well?"
So reading thru the comments, I see my personal favorite of using yellow sticky notes is not a good idea?
Check out my sci-fi/humor trilogy at PatriotsBooks.
So when you find some critical bug in that code, you'll have to hunt down every copy and update them as well. And if you make some l33t optimization to the code, you need to update every copy to get any speed advantage. Yes, really smart and simple, that.
If you don't want to use external databases, then simply break the code down to one logical unit per file, and use soft/hard links to bring them to every project that needs them. That way any bugfix/speedup affects every program immediately, and you don't get hundred-plus versions of code floating around and causing trouble.
Giving some thought to technical details avoids giving a lot of thought to solving the problems caused by lack of attention to details.
When he is a manager, he can get his underlings do copy-paste maintenance all day long. As long as he's working alone, he is the one who has to fix his fuckups. So he needs the robust system now, not in the future.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
>I'm making a Low Budget HDV Filipino Horror Movie in NY [griefmovie.com]
To be very honest, it's not very exciting (yet?). Why is the main character walking around so slowly? The telephone conversation at the beginning... Well, no-one talks like that in real life. Am I missing something? Is it that I'm Dutch and don't get it?
Considering all the praise we read about Subversion, and its compelling features list, we switched a medium size project (80000 loc) from CVS to SVN. All in all we are not impressed with Subversion, and are not going to use it for new projects (for the forseeable future).
The bad things:
svn import: oops, there is a some experiment data in the directory, or an AAP subdirectory. Shit, the repository has grown by another 100 MB. No way to get it out again, unless you convert the whole BDB database to text, find your accidental additions, cut it out, rebuild the database, do svnadmin recover, fix all the permissions.
Really wrong error messages.
" unable to get lock on file blabla". You'll now have to manually do svn rmBig errors:
Having moved our repository to another server, we have had situations where a subdirectory was pointing to the new server, and its parent to the old server. When we did an svn update in the subdirectory, the updates would not happen and no error whatsover was given. Worse, to prevent this kind of problems, we had renamed the repos directory on the server, so that there was no way some dangling old links could accidentally access it.
Adding files to a repository from multiple places around the lab has gotten us often into troubles
The Berkeley DB format keeps changing. You can't just copy one to a server with a slightly different svn version. Worse: it will not tell you that there is a version difference, it will just try, and come up with the most irrelevant error messages.
All in all, we find SVN not ready for prime time. Its promises are great, but at least CVS is just working reliably.
This code is going into the Space Station (Declic), version control is a must for us.
I keep all my PHP functions in a single file called functions.php that I include in all my PHP pages that need something from it. I keep all my PHP classes in a file called classes.php that I can include in pages that need those. I _could_ create a single Utility class that would hold all the functions to keep all the stuff I need in the one classes.php file, but I am lazy.
I keep all my Javascript functions in a file called functions.js that I on all the pages that need those.
--- Nothing is secure.