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?"
Use CVS or some other revisioning system.
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.
Inventing something once is Genius. Inventing something twice is stupidity.
Using OOP, code should be reusable without having to have some external database. I find that the more external processes one has, the less likely one is to use it.
Code should be self-documenting. I'm not saying you don't have external documnenation... just that well written code has good comments. A good practice is to comment function and classes before coding.
Break things down into components. Refactor. Then your code will be very reusable.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Store you code on a disk or a tape. If you store it on a printout, you'll just have to type it in again.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
I run a small web dev firm that does a lot in the way of PHP and JS, like yourself. What we have found works the best for our core library is a copy of Subversion running on our server. This way we all know exactly what the latest version is, and more importantly we can see how it became the latest version (i.e. what changes were made). A lot of tools run with SVN nicely. For instance, Trac talks to a backend copy of SVN and couples it loosely with a wiki and a couple of other things. A lot of hosting providers will also run a copy of SVN for you, like http://networkredux.com/ (We just switched over to them).
Of course, a root level folder on the ftp server can also work.
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/
He's new and self-taught. Cut him some slack. I started becoming self-taught on a TRS-80 Model I. The code I wrote was a joke. I picked up lingo along the way. After getting away from computers, I re-entered the computer programming field, only to be faced with a new paradigm -- OOP, n-tier apps, etc. It took a lof of reading, wading through different opinions on design, idiots who have written a lot on the subject and don't know what they are talking about, etc. It was a lot to absorb, but after a few years of trial by fire, think I am on top of these things.
He is at the beginning of the curve. Laughing at him won't help.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
In the real world, though, I just copy code from previous projects into the new one as needed. I'm usually careful about keeping things modularized so this hasn't been a problem so far, but I tend to forget what I was doing on my old projects and have to spend time figuring that out.
I'm not sure if there's software for this or not. Did you try searching for 'code' on freshmeat? :)
>What I don't think is ok is being ignorant and asking others for advice without doing any basic research yourself.
I'm all for bashing Ask Slashdot questions that should be Googled and "Do my homework plz" type questions but he really just a kid (look at his homepage).
Kids are suppose to be ignorant and ask advice about really basic stuff.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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
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
Get a subversion over http (apache) server going and turn on web-dav auto-commit.
)
This way you can have full version control with a client like Tortoise SVN and read access to any file with any web browser.
The web-Dav auto versioning will allow you to write to any of your files with any web-dav client including windows explorer, internet explorer, ms visual studio, macromedia home site, cold fusion studio, many other development environments, microsoft office and lots more.
Subversion info: http://en.wikipedia.org/wiki/Subversion_(software
WebDAV info: http://en.wikipedia.org/wiki/WebDAV
Subversion: http://subversion.tigris.org/
Tortoise SVN: http://tortoisesvn.tigris.org/
I usually print it out and staple it to a squirrel. Then I set the squirrel free, because information wants to be free, and so do squirrels with paper stapled to them.
I think this is what people mean when they talk about libraries and/or APIs, but not really sure.
Not quite. What you are talking about sounds like just a repository of random code. A library is a specifically designed set of code to perform a given task or set of tasks. There's a certain amount of order implied in the term just as is implied by that big building where they put books.
API's are designed interfaces to a system to make coding easier to do. You don't have to understand how the underlying guts of the code works, you just program to work with interfaces. So you call the draw() method and a line appears on the screen but you don't need to know how to speak directly to the video card, etc.
AS for the original question, I have two suggestions. The first is to use CVS as a way to version your code. It's like have CTRL+Z for your entire project. It makes it much easier when you are adding new code because you can feel comfortable breaking it completely because you know you can revert it easily.
The second is to use a simple search engine to catalog your code. Google desktop would be up to the task. Just check out your code from CVS and put it in a directory somewhere. Then when you need code for some task you can search for it. If you're good about commenting your code, that should work like a charm.
This sig has been temporarily disconnected or is no longer in service
to retrieve that information
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
I'd say asking the slashdot readership IS doing research. If you've got time to flame him for asking a question clearly you weren't too busy to respond to his question.
The smartest way to get knowledge is to ask the people that know. And by posting on Slashdot it's not like he's barging down your door or sauntering into your cubicle and demanding your attention. It's a very passive non-intrusive inquiry. You read the post, you responded, you have no reason left to complain about this.
Plus, as a largely self-taught programmer myself I know that asking a question from someone who knows can sometimes get an answer 10 times faster (and 10 times more clearly) than reading a bunch of manuals frequently written either for dummies or for experts. That in-between period when you don't need someone explaining how an if-statement works but you don't really quite know the next step is a difficult phase. In my opinion this isn't a question of laziness - it's a question of efficiency. There seem to be plenty of people here who want to help him. Why don't you kindly get out of their way?
-stormin
The Southern Baptist Convention has creationism. On Slashdot, we have porn.
I can't believe his age is even being discussed. He could be 33 for all I care. since when is it a crime to ask a question? Again - he's not wasting anybody's time. Anyone who resonds to this thread to complain about him proves they have the time to deal with the issue at least a little bit.
I think it's crazy that some poor guy manages to get his question posted on slashdot - which means he's probably going to get a wealth of information - and he ends up having the legitimacy of his question debated in terms of his age!
It's people like this that give techies such a bad reputation. It's one thing to laugh in fun at the dumb users who try to use the CD-drives as cup holders. It's another thing to get irritated with users who expect us to fix their messes after the screw stuff up. But to smack down someone who's actually trying to learn to do it on their own because you don't like their question? That's just elitist and anti-social.
-stormin
The Southern Baptist Convention has creationism. On Slashdot, we have porn.
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?"
You do what i do, you put everything in one file and call it "misc" and then link it to every program you make. problem solved.
If it's not sensitive, and I wouldn't mind people using it, I like to store it on my tagged code snippets site. It helps me find useful bits and pieces again at a later date as I can always remember a word or two which I tagged it with. 1000 other users seem to enjoy it too :) and if you're looking for inspiration you can subscribe via RSS.
Since this is 2006, there is no point in starting with CVS.
Use SVN if you will be the only person committing stuff in to the repository. If you plan to share the code in an Open Source project with many people, and each will have their own distributed repository, then look into something like bzr from Canonical.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
... to erase it.
To Chuck Norris. He's got infinite storage space, but recovering the files will almost certainly involve a roundhouse kick.
There's nothing worse than coming back to your code a year later and asking, "What the *&$#^& was I thinking here?"
Not true.
You could come back to your code a year later and think: "What the...? What kind of "Teach yourself C in 24 hours" mental midget committed THIS? This idiot should be fired... into space! He's...uh... oh, damn..."
It may be all you *need* to get started, but I'm sure you know that PHP's OO these days is quite stellar. PHP 5 classes are now complete, with the whole OO shebang: polymorphism, encapsulation, interfaces, C++-like exception handling... the only thing that it doesn't support, and I'm not sure it *is* strictly necessary, is multiple inheritance. For the rest, you should try PHP 5, it is a very mature language and, IMHO, quite suitable for general purpose programming, not only web pages, even more so with the recent release of PHP-QT (there is already a PHP-GTK if that's your poison) for stand-alone GUI applications.
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
Storing your code is just the beginning.
But to start, use SVN. There's not a good reason to use something else, and having the history of your changes will (in some ways) be far more important than having the code itself. If SVN is a bear to put up with, and it's just you, you might consider RCS, but RCS will eventually make you jump through so many hoops that sooner or later you'll be looking at SVN.
After that, you'll need to recode your code to become more useful over time. At first, the solution fits the problem, and the problem fits the website, and that fits the specific task you were trying to perform. After some time, your needs will change. The second time you want to use your code, you'll notice that it doesn't really fit. This is where your challenge starts.
Challenge yourself to NOT write the 2nd and 3rd products that use your code to make compromises for the "way this library needs to be used". Rework parts of the library to make it more useful in more situations, and rework both the old and the new projects to use the new library.
Then try to make a third application that uses the library in a slightly different way. Once again, don't write the application to fit the library, but modify the library to fit the way the application uses it. At the same time, check that the old applications both keep working on the rewritten libarary's code, and keep them up to date with the changes in the library.
After a few trips on this merry-go-round, you'll begin to notice a few things about code maintenance, code reusability, and code maturity. Sure, you could just read about it in a book, but that would rob you of an education. You MUST see it happen in person to understand it. If you're doing things "correctly" you'll notice a few things:
1. Each time you write a new applicaiton, the library needs to change less and less, but it's still easy to use.
2. Good libraries don't force different applications to be written the same way. Bad libraries require the application to be written in ways that make using the library uncomfortable.
3. It's impossible to make code reusable without some understanding of the various ways you might be likely to use it.
The real test is when you find yourself writing documentation for your library so you can hand it off to someone else to use without the need for them to see your source. Sure, you could give them a copy of the source code too, but if they have to read it, you've only made it reusable for you, and that's a small audience to learn from.
Good luck, and don't worry if you fall short. Writing good, flexible, reusable libraries is often much harder than writing the applications that use them. Just remember, it's not a library if only one application uses it. It's not flexible if only one style of application uses it. It's not good if you have to read it's source code or documentation that looks like it could be source code.
Sincerely,
ELB
This is one of the most complex problems in the realm of computer science, and the answers to this question are less than obvious.
.. I find that a typical Euler-lagrange transformation works a treat, especially when numerising C code.
.. you now have a basis for a firm statistical analysis, and you are now on the road to the enjoying the luscious fruits of code-reuse.
.. and that these structures are also .. you guessed it ... a six sized pyramid with a structural ratio of 2/pi. One more peice of evidence which confirms the widely held (but seldom admitted) secret knowledge that the ancient Sumerians were masters at the art of computer science.
.. ah .. yeah, there you go. You should reduce your code to numbers, store it in a hexa-pyramidical structure, and continue to statistically analyse the usage of these functions until such times as your hexapyramidical representation of those functions reaches an ideal ratio of 2/pi. At that time, you know that you will have reached a higher plane of computing expertise. Take pleasure in this moment and revell in it - but be aware that such knowledge only opens the doors to longer and steeper pathways, beyond which lay more secrets yet to be uncovered.
What you need to do is reduce your code samples to a numerical matrix, assigning weights to various functions co-dependant upon the language that is being used in each case.
These matrices can then be overlayed in an N-dimensional space, and the resulting eigenvalues plotted
For C-like languages (such as PHP), then a modified transform, such as the "saddlepoint" method used by Ridderinkhof and Loder is often more appropriate.
Once these transforms have been completed, computed, stored and plotted
Now you need to apply that numerisation of the coded functions across an (N+1) dimensional space, which is in fact - the source code to which the said functions have recently been applied. Time scale here is critically important - as the most recently used invocation of a function must by the merits of its use, hold a higher weight than one which has not suffered invocation for some considerable period. This is the much-discussed 'Wolverton-Hasselby functional relevance decay factor' which is often the subject of many a debate in computer science circles.
Having thus reduced the chaotic collection of functions to an orderly numeric topology (the graph of who's actual usage forms an ever-revolving surface spread across a time-dependant dimensional plane), we soon find by observation that the collection of functions now forms a pyramid.
Further quantum statistical analysis of this ever growing and ever evolving collection of co-dependant functions will reveal that the structure of this grouping forms not just a pyramid (no surprises there), but a SIX SIZED pyramid !! A pyramid with the base of a perfect hexagon is formed when this numerical matrix is rendered as a 3D image.
The ratio of the height of the pyramid to the size of the base is the value of 2/pi.
There are writings in Babylonian that hint at the architecture of the inner structures concealed within the Ziggurat of Ur
So
Best wishes on your journey
Interesting site you have there, btw. Is that really you? You're so dreamy!
"Our interests are to see if we can't scale it up to something more exciting," he said.
From my experience: :)
- If you have unit tests, keep them with a copy of the program that runs them.
- If you dont have unit tests keep a running little example of how to use it - and start looking into using test-driven development for these pieces of code you'd like to rely on.
- have a 'code blog' in a plain txt file where you track some of your main decisions and ideas to-do. As time goes by, I have tended to idealize my past code into doing things I had only wished it did
- If the code uses databases, external files, etc. keep those too
- If there are interesting things that need to be done during build, make sure you keep those too
- Choose some SCC mechanism, svn or whatever suits you, plenty of posts...and archive a plain copy of the
- if you plan on archiving for maaany years and writing in some propietary lamguage, keep a version of the editors & compilers safe with your code. I had to rehash a lot of prolog once.
Now, there's a few caveats here. Another thing that happens over time is you learn to stop re-inventing the wheel and to use pre-existing libraries. Right now, you're just unaware of their existence, but you'll learn where to look if you make a little effort. In fact, you'll find that existing libraries tends to heavily influence choice of language to use. So it turns out that most things that are really worth reusing are already available, and you should use those solutions rather than maintaining your own. Sure, write your own for fun or education, but when you get a serious project, you've got no use for it. In some cases, you'll find that there's no library available, so you write something from scratch, but 3 years later, you find that somebody else has made a nice library that's much better than what you hacked together. Several times I have ported code from my own hacked together solution to a more mature library. It's a natural progression, and there are a thousand times more libraries freely available today versus 10 years ago.
Now, having said all that, there are still times where you want to make something that is generically reusable. The point is, though, you should really make an effort to make a library out of your code. I have done just this on a handful of occasions. Then, put it up on SourceForge or something similar dedicated to your language of choice. I have a few libraries up on SourceForge, some only a few hundred lines of code, but some other people have found them useful because I made the effort. Other people have suggested CVS or whatnot, and SourceForge will give you that.
Maybe the real gist of your question, though, was about making your code into a library? While the technical details of making a lib, dll, so, jar, pm, etc vary from language to language (sometimes compiler to compiler), here's a few pointers:
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.