I've had good luck with fastmail.fm as well but I'm not having good luck with them right now. I've not been able to check my fastmail.fm mail since Wed. night. And, according to their blog:
At the moment, it looks like it will take another 30 hours to finish checking the filesystem, at which point hopefully we'll be able to get these users working again.
"Hopefully"?!? You do not want to hear engineers saying that word. And 30 hours from the time of that post in my timezone means Fri. at 8:10 PM. I will have been out of my fastmail.fm email for close to 40 hours at that point.
If you want stable software perhaps one of the most important things you can do to stack the odds in your favor is to keep your system as simple and clean as possible. The idea to completely decouple the application from itself seems complex rather than simple and thus could serve to reduce reliability rather than increase it. I really strongly recommend not getting that complex from the get-go especially without any empirical evidence indicating that the complexity is absolutely required.
The restart logic to bring parts of the system up that fail also seems like it could have a net-effect of reducing reliability. Such restart logic will almost certainly be complex and thus problematic. I recommend instead a different error handling paradigm: whenever anything pathological is detected your program should "panic" (quit in a graceful way) and tell you exactly why it panicked (perhaps by printing out a stack trace, perhaps by printing out the exception's.what() string and making sure all possible exceptions produce uniquely identifiable strings.) In the course of development every time a panic happens you will know why and so will be able to resolve them quickly. Given this sort of discipline, some good engineers and the proper development schedule by release time you will have worked all the common panics out of the system.
The advice to use some sort of agile software development process and automated unit-testing is spot-on. Check out cppunit (http://cppunit.sourceforge.net/cppunit-wiki). I use cppunit extensively and it helps me greatly. Making the application unit-testable will increase its complexity somewhat, but this complexity increase is usually not too great and will prove to be insanely worthwhile given the advantages of having an automated unit-tests testing that your software still works at every build.
Think carefully about your Makefiles/directory structure. Again you want something simple. But you also want the build system to do some things for you like auto-generate the dependencies of your.cpp files and invoke your unit-tests as part of the build. Make sure you build system refuses to output an application binary if any unit-test fails (this is quite easy to do with make and cppunit.)
The advice to utilize STL and exceptions is also very good. There is no need to reinvent the wheel when you can leverage STL. Make sure you do some reading about exceptions to avoid making a big mess, but they are absolutely worth learning and using.
Really, really try to stay away from threads. Threads imply complexity and it is hard to get them right without great discipline and some experience.
Reading:
The C++ Programming Language by Bjarne Stroustrup
This is worth having around as a reference. It is a bit heavy as a tutorial but it will be able to answer many the strange questions that come up about C++.
Effective C++ Third Edition by Scott Meyers
(Getting the THIRD (newest) edition in particular is important.) C++ has a learning curve that's a bit steeper than many of the other modern OO languages. This book helps you up that curve as quickly as possible (assuming you already know the basics of OO software design and languages.) Very good advice about why you should use the "auto_ptr" (that others mention) when you allocate memory on the heap. Advice about exceptions. Lots and lots of other lessons can be learned from a quick read that will save you so much time and pain the long run.
Agile Software Development by Robert C. Martin
Others may disagree with this recommendation. I think there are several similar books. This is the one that I happened to encounter and I do not know if it's the best. I do know it is sufficient at giving a broad overview of many important concepts like: agile development processes, unit testing, OO design principles, design patterns.
The biggest problem in society today is our government is out of control. The reason that is the case is because the public is uneducated
Your argument is contradicted by the fact that this legislation is happening in Massachusetts which has been ranked the "smartest" state in the country several years running (See: http://www.morganquitno.com/edrank.htm).;)
They should also not be allowed to advertise a calling plan for $29.95 a month, and then tack on $14 in "taxes and regulatory fees", which no doubt will go up even MORE after this useless "bill of rights' is passed.
This is exactly one of the things that the proposed law would do. I thought you were against it?
From the text of S.B. 1790:
Section 117. (a) The department of telecommunications and energy shall promulgate regulations requiring that any publication, including publication on the internet, of a wireless telephone service provider concerning the terms of its plans or contracts for wireless telephone service shall set forth, in a plain and conspicuous manner, the following information:
...
(4) Information on taxes to be collected by the carrier for, and paid to, a state, local, or other governmental agency.
(5) Information on surcharges imposed by the carrier for the costs of compliance with regulations or for other purposes.
Slashdot Mirror
I've had good luck with fastmail.fm as well but I'm not having good luck with them right now. I've not been able to check my fastmail.fm mail since Wed. night. And, according to their blog:
"Hopefully"?!? You do not want to hear engineers saying that word. And 30 hours from the time of that post in my timezone means Fri. at 8:10 PM. I will have been out of my fastmail.fm email for close to 40 hours at that point.
Think twice about fastmail.fm.
The restart logic to bring parts of the system up that fail also seems like it could have a net-effect of reducing reliability. Such restart logic will almost certainly be complex and thus problematic. I recommend instead a different error handling paradigm: whenever anything pathological is detected your program should "panic" (quit in a graceful way) and tell you exactly why it panicked (perhaps by printing out a stack trace, perhaps by printing out the exception's .what() string and making sure all possible exceptions produce uniquely identifiable strings.) In the course of development every time a panic happens you will know why and so will be able to resolve them quickly. Given this sort of discipline, some good engineers and the proper development schedule by release time you will have worked all the common panics out of the system.
The advice to use some sort of agile software development process and automated unit-testing is spot-on. Check out cppunit (http://cppunit.sourceforge.net/cppunit-wiki). I use cppunit extensively and it helps me greatly. Making the application unit-testable will increase its complexity somewhat, but this complexity increase is usually not too great and will prove to be insanely worthwhile given the advantages of having an automated unit-tests testing that your software still works at every build.
Think carefully about your Makefiles/directory structure. Again you want something simple. But you also want the build system to do some things for you like auto-generate the dependencies of your .cpp files and invoke your unit-tests as part of the build. Make sure you build system refuses to output an application binary if any unit-test fails (this is quite easy to do with make and cppunit.)
The advice to utilize STL and exceptions is also very good. There is no need to reinvent the wheel when you can leverage STL. Make sure you do some reading about exceptions to avoid making a big mess, but they are absolutely worth learning and using.
Really, really try to stay away from threads. Threads imply complexity and it is hard to get them right without great discipline and some experience.
Reading:
The C++ Programming Language by Bjarne Stroustrup
This is worth having around as a reference. It is a bit heavy as a tutorial but it will be able to answer many the strange questions that come up about C++.
Effective C++ Third Edition by Scott Meyers
(Getting the THIRD (newest) edition in particular is important.) C++ has a learning curve that's a bit steeper than many of the other modern OO languages. This book helps you up that curve as quickly as possible (assuming you already know the basics of OO software design and languages.) Very good advice about why you should use the "auto_ptr" (that others mention) when you allocate memory on the heap. Advice about exceptions. Lots and lots of other lessons can be learned from a quick read that will save you so much time and pain the long run.
Agile Software Development by Robert C. Martin
Others may disagree with this recommendation. I think there are several similar books. This is the one that I happened to encounter and I do not know if it's the best. I do know it is sufficient at giving a broad overview of many important concepts like: agile development processes, unit testing, OO design principles, design patterns.
Good luck with the system!
The biggest problem in society today is our government is out of control. The reason that is the case is because the public is uneducated
;)
Your argument is contradicted by the fact that this legislation is happening in Massachusetts which has been ranked the "smartest" state in the country several years running (See: http://www.morganquitno.com/edrank.htm).
This is exactly one of the things that the proposed law would do. I thought you were against it?
From the text of S.B. 1790:
See: http://www.mass.gov/legis/bills/senate/st01/st017