Just that I've been researching for SQL solution for NodeJS and MySQL, and saw a lot of good things about dbslayer. But it's been more than 4 days that I couldn't connect to both code.nytimes.com and www.dbslayer.org, hence neither could I install and try dbslayer, whereas I saw cherokee included dbslayer in itself. So I'm wondering if anybody know the current status of dbslayer development? Thanks in advance!
The official Github repository seems to be this one, what is indicated by this Tweet and the referenced tumlbr post. This also indicates that Derek Gottfrid was the main responsible person for the project, who posted on Twitter last time in october 2012 about this project.
Since the last changes at Github are multiple years old and there are practically no Tweets about this on Twitter anymore, I would call this project dead.
According to http://sourceforge.net/projects/c3p0/files/bin/ it seems that the last stable version of c3p0 was released in 2007.
Isn't it abandoned project?
We use it heavily and it works fine, but I am a little bit afraid that it will not get fixes and support, causing that new versions of hibernate, JDBC drivers, databases and finally transition to java7 will make it work worse.
i've been in grad school in an unrelated field since 2007, which has kicked my butt and rendered c3p0 maintenance slow at best. c3p0 is not formally abandoned, but until i'm out of this program, it defacto has been. (the update from ~1.5 yrs ago is a pretty big deal, and i've gotten no bad feedback on the changes, i advise using that. but it was a one-off, not the long sequence of release and feedback that i upgrade to a stable release.)
i do intend to bring c3p0 forward when i am done, which will hopefully be this summer. but i mostly feel terrible about the long lapse in maintenance, and understand apologetically that many users have felt compelled to seek alternatives.
c3p0 development has started up again, with a new release (c3p0-0.9.2-pre2).
We switched to BoneCP because we had some IOExceptions on high load we could not fix. After switching to BoneCP everything run fine. we are driving a very high volum site with peaks of 3000 dynamic page views per second and I can really recommend BoneCP.
In 2020 I would recommend HikariCP. It is very fast, stable and has excellent documentation.
I'm in the process of going back over some of the more minor TODO's in my code. One of them is in a class that handles partial dates, e.g. Jan 2001. It works fine for dates that will be seen in our system (1990 - 2099) and gracefully fails for other dates.
The TODO that I've left for myself is that I don't handle dates in the century 2100 and beyond. I don't really think it worth the effort fixing this particular problem, but I am cognisant of the Y2k bugs. If we were in 2080 already I think I'd be thinking differently and would fix the bug.
So how long does code last for? How far ahead should we plan for our systems to keep running for?
Update
Ok, thanks for all your input. I think I'm going for the option of leave the TODO in the code and do nothing. The thoughts I found most interesting were:
#Adrian - Eternity, I think that's the most correct assumption, your point about VM's is a good one.
#jan-hancic - It depends, yes it does.
#chris-ballance - I'm guessing I'll be dead by the time this restriction is hit, so they can come defile my grave if they want, but I'll be dead, so I'll just haunt his ass.
The reason I decided to do nothing was simple. It added negligable business value, the other things that needed looking at did add value so I'll do them first and if I get the time I'll fix it, but really it'll be nothing more than an academic exercise.
Longer than you expect.
Eternity.
Given the trend that old system keep running in virtual machines, we must assume that all useful code will run forever. There are many system that run since the 60ies, eg backend code in financial sector, and there seems to be no indication that these systems will ever get replaced. (And in the meantime, the frontend is being replaced every other year with the latest fad in web technology. So, the closer your code is to the core of your system, the more likely it will run forever.)
You can't have a general answer here. Depends on what kind of project you are building.
If you are writing software for a space probe then you might want to code it so that it will work for the next 100 years and more.
But if you are programming a special Xmas offer for your company's web page, a few weeks should be enough ...
Assume that whoever will maintain the code is a psychopath and has your home address.
Nobody really knows. Professional programming has been around for 30-40 years, so nobody really knows if code is going to last for 100 years. But if the Y2K bug is an indication, it is that a lot of code is going to stick around for a lot longer than the programmer intended. Keep in mind that even if you take that into account, it could still stick around longer than you expected. No matter how much you prepare, it might still outlive it's intended life expectancy.
My advice is to not plan for code to last 100 years. Instead try to make sure all your code will work for the same length of time, that is, part of it should not fail in 2 years, while the other part should fail in 100 years. Remember, you should always fix the weakest link first, so there is no point making the strongest link stronger.
Sometimes, code lasts longer than you think. But, more important is the slippery slope argument. Once you forgive yourself a bit of non-bullet-proofness, you may be tempted to optimize further and skimp on logical correctness, until it finally bites you.
By the way, I recommend to have an issue ID (such as FogBugz case number) in every TODO comment, so that people can actually subscribe to and track this TODO.
in Dan Bernstein's immortal words: Don't contribute to the Y10K problem!
I don´t think the code will last so long.
Think about all the inventions and progress made in the last 90 years.
In 2100 we won´t have to write down code.
There will be some kind of brain-machine interface.
Well, we recently made a timestamp format where time is stored in a unsigned 64-bit integer as microseconds from 1970. It will last until the year 586912, which should be enough.
Coding for "forever" is unnecessary - of course you could use BigIntegers and such everywhere, but why? Just be prepared for more than 5 or 10 years. Twenty year old production code is not quite unusual nowadays, and I suspect that the average life cycle will get even longer in the near future.
It depends on how much business value the code has and how much resources it takes to write it from scratch. The more value and resources the longer it lasts. Ten years and more is typical for commercial "works, don't touch it" code.
I always tried to code like my applications must work "forever". I am very sure I wont be around anymore in 2100 but knowing my software has a build in expiration date doesn't make me feel good. If you know about such things try to avoid them! You will never know but some unknown programmer in the future may be grateful.
Right up until the time that it breaks, or otherwise ceases to be useful, and then for a bit longer after that
The essential things are:
How good is your internal date class (get a very robust library version and stick to it!)
It's not just the passage of time, but also the growth in the range of inputs your users want. For example, maybe you have 30 year mortgage inputs now, but next month someone decides to input a 99 year lease with maturity 2110, or a 100 year Disney bond!
If you accept 2 digit year inputs with a date window, think very carefully about how that is applied to start and end dates, and give lots of immediate feedback.
Here are my two cents:
When we design a project, we usually declare it to last "at least" 5 years. Usually no more than 10 years before we re-design it and build it all over. (We're talking about mid-large size projects here).
What usually happens is that the new project you build is supposed to replace the old one, either techonology wise (i.e. moving from MF to windows, VB to .net etc.), but this project never ends. So your client ends up working with 2 systems at once and that leftover system is what later is referred to as "legacy".
If you wait long enough, a third project will rise causing the client to work with 3 systems at once and so on...
But to answer your question, I would bet on 5-10 years before redesign, and unless your dates are supposed to be long into the future - no need to worry about the 2100 limitation.
IMHO it comes down to craftmanship : the pride we take in our work, coding to a standard we would not be ashamed another real coder to see.
In the case of dates like this, you've stated that it gracefully fails after 2100. This sounds like you can remove the TODO without a bad conscience, because you have built in a response that will allow the cause of failure to be easily diagnosed and fixed in the (however likely or unlikely) circumstance that a failure occurs.
There are examples of code running on older machines which is 40 or 50 years old.
(Interesting bits in this thread: http://developers.slashdot.org/developers/08/05/11/1759213.shtml).
You've got to ask yourself about the nature of the problem you're solving but generally speaking even "quick fixes" will be around for years so you could realistically be looking at a decade or more for code intended to have a decent shelf life.
The other things you need to think about is:
1) What is the "active life" of the application - that is where it's going to be used and processing.
2) What is the "inactive life" of the application - that is it's not going to be used day to day but might be used for retrieving and viewing old records. For instance UK audit law means that records need to be available for 7 years, so that's potentially 7 years from last system use.
3) What is the range of future data it needs to handle? For instance say you're taking down credit card expiry dates - you can have a card which won't expire for a decade. Can you handle that date?
The answers to these questions will generally lead you to the assumption that you should never knowingly write code which has date constraints beyond those the OS/Language you're using dictates.
The question isn't "How long does code last?" but rather "How long will things in my code affect an application?"
Even if your code is replaced, it's possible that it will get replaced with code that does the exact same thing. To some extent, this is the direct cause of the Y2K problem. More to the point, it is the direct cause of the Y2038 problem.
Also keep in mind what you mean by last.
For example, the original UNIX operating was developed 30 years ago. But during that 30 years, the product has evolved over time.
Though, it wouldn't surprise me if a little but of original code still exists in it today.
So think of it 2 ways ... 1) do you ever antisipate the code being touched in the future, 2) the product/code will evolve if you have support and involvmment.
My current shop has a large code base that runs financial applications with complex business rules. Some of these rules are encoded in stored procedures, some in triggers, and some in 3gl and 4gl application code. There is running code from the late 90's, and none of it in your "traditional" Legacy languages like COBOL or FORTRAN. As one could imagine, it's a steaming pile of spaghetti code, most created before TDD meant anything, so people are reluctant to touch anything.
I have had occasion to be brought in on contract more than a decade after the fact to consult on porting code to a new platform (OS/2 just isn't that popular these days!). When in doubt, assume that your code will live longer than you will. At the very least, document the heck out of limitations like this; fix them unless that takes tremendously more work than to document them.
In 1995 I started work at a new job, on an 8 year old code base.
So it's incept date was 1987 or thereabouts.
The code is probably still in service. Thats what ? 23 years.
There's been some moves of the company, but they probably kept the software ( because it works)
If it's still in service now, it will still be in service in a decade or so.
It's not surprising, particularly high tech code, in C (mostly)
In 1999 I started at a new job, the the codebase had antecedents back to 1984.
The new version I designed in the 2000's is still in service, with design elements like data file formats from the previous one ( and so on back) and that would be a development program over 26 years.
So the year 2086 problem is starting to loom a little as those 32 bit signed time_t's roll over.
Remember that one of the major bonuses of modern programming is reuse.
So that means the code you write originally to solve one problem may get re-purposed and used in a completely different scenario years later (maybe even without your knowledge, by a team mate).
As a side note:
One of the major pluses of automated unit testing, is testing code that you can't even remember is there in a system! :)
As long as people can continue to bill for support with people willing to pay for it.
3-5 years max. After that you have moved on to another job and left your crappy code behind.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
It seems that the normal progression to join projects is to contribute for a while, earn the trust, then get accepted as a member of the community (i.e. having commit access).
Now, I already apparently know "the best way" of how to get involed, in a manner of speaking; this is not my question; what I was hoping to attain is: How did everyone else get involed? Surely not everyone has gone down the "find a project and submit patches" route - or have they? I dont happen to know anybody in the open source community, so I'm just itching to know...
Perhaps you already knew someone in a community and just fell into it? Maybe you were getting frustrated with some bug and started contributing regulary as a result? Maybe you did just spot a project on SourceForge...
Update:
It seems that the most common reason is simply scratching an itch, to quote singpolyma: "Looking for a project to contribute to is often not the right way." Instead, you should join the open source community by contributing to a project that you already know and use.
Important:
Please, please, please: Tell me about your specific experience, no general answers please. Also, answer only if you are either a project member or a patch contributor. Please do not give advice on how to join a community, this isn't the kind of answer I'm looking for. If you would like to give advice on joing a community, please answer in this other thread.
Great Answers:
Mark Harrison talks about Tcl, cx_Oracle, kap and orapig
singpolyma talks about DiSo and Greasemonkey
Pax talks about contributing to GnuCash because of his wife
Related:
How to get involved in an open source project
How Open Source Projects Survive Poisonous People (And You Can Too)
My personal anecdotes:
I got involved with the Tcl community when it was first starting out in 1991 or so. The mailing list and later the usenet newsgroup were pretty important to connect with people. I specialized in user evangelism and teaching, and eventually ended up writing two books about the subject. One of them is still in print after ten years:
http://www.amazon.com/dp/0201634740
Now I use a lot of Python, and really like the cx_Oracle package. Again I was active in the mailing list, and contributed a few patches.
I've made a couple of software packages available that I had written for work. By making them open source, I was able to get some nice contributions back, and since they were not the "secret sauce" of my employers at the time, they didn't mind sharing the code. The two most popular packages were
http://sourceforge.net/projects/kap/ The Kinetic Application Processor -- this was built when I was working on the China Internet backbone.
http://code.google.com/p/orapig/ - OraPIG, the Oracle Python Interface Generator -- it generated Python code to call APIs defined in the database, and includes an XML-RPC database interface.
Advice:
Instead of looking for projects to join, try contributing to projects you already use.
It's often difficult to jump into the "core" development, because (a) on a big project, that might be a pretty big chunk of code to understand, and (b) there are probably a core group of people already working on it.
So, suppose you like a certain piece of software and want to start contributing, you can start working around the edges. Here's a couple of concrete tasks that will help you to become integrated with the group.
write some test cases for bugs to add to the regression test suite.
browse through the bug database and find a bug to work on. This might be the best way to get into the core development.
look at the feature request database and see if there's a small task you can work on.
look for "user doc" requests... a lot of them involve writing example code which you can provide.
Good luck!
The way people normally get involved is:
you use the FOSS product in your day to day work
you notice a problem or a missing feature
you mail the maintainer to ask if this bug/missing feature is real
the maintainer says yes, this is a bug/missing feature
you decide to try to fix/add the bug/feature
you code like mad
you submit a patch to the maintainer
the maintainer laughs in or face or says "thanks very much!
If you repeat the last few steps a few times, the maintainer will probably give you commit access to the project's RCS repository, and then you can really become dangerous. But the bottom line is that it is up to you to do something i.e. write some code - merely being "interested" in a project is not enough.
I joined DiSo and Greasemonkey.
The best way I've found to get involved is to get in early in the life of the project, or just be very interested. With DiSo or the various github projects I'm on, it was the former, with my Greasemonkey contributions, the latter.
Looking for a project to contribute to is often not the right way. Use stuff and find out what you want to build/fix, then do that.
I did a little bit of patch work on GnuCash since my wife restarted work part-time recently after our kids were a little more grown up.
I would've rather had my eyes ripped out with a hot poker than re-install Windows but GnuCash was missing something that [a certain other accounting package] had so I told her I'd get it added.
As it turns out, they took my patch and made it a lot better before putting it in (to the point where maybe 1% of the final patch was my stuff) but at least we can now use GnuCash instead of that proprietary stuff. They were also incredibly responsive - from patch submission to patch availability was only a week or so and it was in the product three weeks later.
I also once investigated getting a patch into the process accounting in the Linux kernel but the effort required far outweighed my needs :-)
I don't contribute on a regular basis, more as-needed (find your itch and scratch it). There are some who make a hobby of it but I'd rather be spending my spare time with the kids and, unfortunately, my employer won't pay me to contribute elsewhere.
That last bit particularly galled me since:
the Linux patch would have greatly assisted our product (and a lot of others).
it was change in behavior of another of our products that degraded the usefulness of our product.
the solution was fairly simple, conceptually (the effort required was testing since a problem would have been high-impact [task switching] and very pervasive [everyone using Linux]).
it would have been quicker to code up the patch than the workaround we eventually implemented.
the workaround is a kludge (p'tooee).
now, nobody in the world has the benefit of our patch (including us).
What I did was pretty simple; I opened one.
I have been joined by one permanent developer, and other two who donate code behind the scenes. The project is in very early stages, so not many users have downloaded it.
What really helps an open source project is having a plugin architecture.
It's much easier to contribute a simple plugin for eg. a file format than to try to add something to the Linux kernel. This makes it a lot quicker and easier to build a community.
TODO: Please supply an anecdote.