To Do's

1. Try to insert const both in parameters and return values
2. Make the ToString()'s in the specific events final
3. Use DENY_COPY whenever possible
4. Add a virtual dtor to the GlobalEvent class
5. Use explicit for every constructor with at least one argument
6. return reference to *this from assignment operators
7. In the assignment operators, check for self assignment
8. Create shared_ptr's in standalone statements and then pass
9. Pass by reference-to-const for everything that is not built-in type, or STL iterator, or function object
10. DO NOT return reference to a locally defined objects or reference to a heap-allocated one; if a new object needs to be returned return an object
11. Make all data members private, never public or protected
12. Postpone variable definition as long as possible
13. Try avoiding dynamic_casts using virtual functions with a better design
14. Try using declaration when you do not need definition through includes
15. Avoid differentiating names by a single capital/small letter; avoid differentiating by 0, o, O, 1, l
16. Understand the protocol well, ask why's as many as you can come up with.
17. Each part of the code is implementing something of the protocol; so, find the connections between the code and the protocol.
18. Only if a part of the protocol does not make sense, consult books on ds.
19. Only if the code syntax or design does not make sense, consult c++ books.

quotes

• Pressure makes diamonds.
• When things are going well, something will go wrong. When things can't get any worse, they will. Anytime things appear to be going better, you have overlooked something.
• ...when you have eliminated the impossible, whatever remains, however improbable, must be the truth
• Perfection is achieved only on the point of collapse. 
• Begin at the beginning, and go on til you come to the end: and then stop.
• A man's brain originally is like a little empty attic; you have to stock it with such furniture as you choose.
• The truth is in the code.
• Measure what is measurable, and make measurable what is not so.
• The first principle is that you must not fool yourself and you are the easiest person to fool.

machine learning

• From Stanford
• From Berkley 
• From Columbia
• From Cornell
• From Madison
• From Caltech
• From Harvard
• From MIT
• A list of MOOCS

Distributed Systems - 1

• Why distributed systems are hard to program.
• cpp reads; and this one
• Some resources on visual c++
• UC Berkley Lectures on Data Structures
• The C++ Programming Language (4th), C++ Primer (5th), The C++ Standard Library (2nd), C++ Concurrency in Action, Secure Coding in C and C++, Real-Time C++
• 1 2
• read
• a brief introduction to rvalue referece; this one along with a discussion has some good links
• debugging in visual c++
• compiler web-book
• a book on c
• a course on distributed algorithms 
• distributed design patterns: 1, POSA books, 2  
• metaprogramming
• c++ templates  
• c++ what-nots
• a short course
• distributed systems an algorithmic approach
• distributed systems principles and paradigms
• distributed algorithms by nancy lynch
• uwm course

MS SDE Intern: Day 1

MSR and MBA interns were checked in before Uni interns: as the latter is the greatest in number. I was tensed more than usual all the time. On my table in the auditorium (?) was two MIT's: a boy and a girl; the boy was a math major, he expressed his interest in ml and computer vision. There was a apparently very confident guy doing internship at MS the second time. It was a huge arrangement - the orientation. There are connector taxis for going between buildings, the campus is big. My manager and mentor are Chinese, the mentor is working at MS for 12 years and before that he used to work in MSR in Beijing; to him development is more real and thus more interesting than MSR's "ideas." I had to set up my PC. I did not get the email account because of some delayed submission of some required info. My mentor tried to help me get my table higher up as it was a bit too low, but I said it was OK, because I could lower my chair; it might not have been a good idea to resist his help. My manager tried to give a over all idea of what the team works: it is too vague so far for me to come up with good questions and I did not even realize what is the source of complexity that he emphasized. All I understood is, there are a lot of components in the reliable and available distributed system and there is no good way to monitor or reason about all the components of the state-full machine; I need to come up with some plan in unison with my mentor. My mentor is probably the main guy for load balancing, hence he lacks enough time to delve deep into this issue of complexity. My manager said, I need to set up goals within first weeks; I think they call it "commitments." Overall, I had the feeling that I am going to be a (albeit tiny) part of something big. I met Aran (?) from Harvard; he is very young, not yet determined if his major would be in math, cs, or biology. He is going to be on our team. My mentor seems a helpful guy. I do not remember his or my manager's names!

Curiouser and curiouser!

1. "I" am an idea among many, though somewhat special, inside of my brain. How is this idea of "I" different from other ideas in the brain - physiologically?
2. From inorganic chemicals life began; but is there a single point of time, after which there is life and before which there was none? 
3. Is aging inevitable?
4. If math is coming from human brain like other ideas, why is it so effective in real world?
5. Where did everything begin, or is this question even valid?
6. How and why religions originated and evolved?

Learn the ABC's

1. Typing
2. Try testing how alert you are