Just asking... It seems like it would fit the definition:
"Rocket-propelled vehicle and payload (the frog is its own vehicle and payload, and can be rocket-propelled via bottle rocket) that takes off vertically (frogs jump), climbs to a defined altitude (frogs can jump consistently to a defined height), flies for a pre-determined amount of time (frog stays in the air a while), and then land vertically on a target (a lilypad) that is a fixed distance from the launch pad (1.5 feet away). After landing, the vehicle must take off again within a pre-determined time, fly for a certain amount of time and then land back on its original launch pad (frogs do this)."
I'm definitely not trying to rationalize inaction. I've become quite tired of being accustomed lately to others' failure, disorganization, and lack of accountability, which might be summed up as "inaction".
And I agree with you. Backing up data, whether it be for email or any type of service/application, is critical for the organization. Caching can be very important too, but just so I understand...
Doesn't a cached mail solution also present its own fault-tolerance issues?
For example, lets assume that you always send users to the name of the mail service provider (myfinancialinstitution.com) backed by multiple names pointing to geographically distributed mail servers that cache and back up GMail. Now your macro point of failure is your own service. You could have DNS issues/network issues, server issues, DB issues, etc. that will still come back to bite you.
That is the problem in my mind. While trying to setup additional fault tolerance, you're conceivably setting up other lines of dominoes to the side of the other GMail lines of dominoes that could fall. So hopefully when your dominoes go down en masse (as GMail did, and as each service/network almost inevitably will at some point), you can easily repoint that name (hopefully still reachable) so that the 100,000 users can be rerouted to GMail (assuming you're using the same ports, settings, etc.). And hopefully the organization was smart enough to allow and suggest their users be able to work remotely, in case the network outage affects the workplace. Also we'd assume the organization hasn't tied their users so tightly to the internal network/services that they can work when almost completely isolated from it.:)
Anyway, you are right. And apologize, because this is all just in good fun for me.
Good point, but anything can fail really. You can add layer upon layer of redundancy and fault tolerance, and then someone explode a nuclear bomb that takes out the right spots in the world's network that totally disables your services. Still, as you say, fault tolerance on a macroscale cannot be ignored. And I'm not saying that GMail would be a great way to outsource email service for a large critical enterprise, but it certainly is fine for the most part for some some large organizations, even if this particular failure is obviously not acceptable and something needs to be done to avoid it in the future. Critical services go down, and people get fired. Organizations learn and grow. Life goes on.
GMail is not really a single point of failure, since they have redundant servers, routers, databases, etc. etc. Although this outage definitely exposed something that wasn't fault tolerant enough. Only a small percentage of companies use more than one mail provider. Most use their own internal one, and more often than not, it is not setup as well as GMail. On top of all of that my organization recently had a full day's email outage, and we'd be having issues for weeks because of a migration. I know of another company locally that lost a good bit of their email recently. Problems like that are normal, and you can't just say people shouldn't be using GMail.
Forget Linux, throw away all electronic devices, and follow these handy tips: 1. Preferably find a wife/husband related to you (the closer the better, because you can trust your blood kin more, but avoid anything closer than 3rd cousins if possible). 2. Squat on a large remote property you don't own (preferably somewhere considered by other folk to be inhabitable). 3. Have 10-50 kids (more than that and you might just be inviting mutiny). 4. Teach kids to how to hunt, fish, and guard the perimeter of the property you're squatting on. 5. Please note that aluminum foil around the head isn't safe anymore because of darn nanotechnology, in fact nothing is completely safe. But making everything from nature is as safe as your going to get, so make everything from all natural materials that you find and grow yourself. 6. Stop reading slashdot. They watch people that read slashdot.
SunOS/Solaris had its heyday already. It is unlikely that it will gain much more share of the market than it already has. While OS X will continue to gain more share on the desktop, Linux will probably end up dominating the server side. But Solaris won't go away.
You'll be a better developer if you work under good developers, challenge them, and seek to understand why they do the things they do.
In addition, look at major open-source projects in the language you'll be using if they exist. For example, as a Java developer, I often looked at Apache Jakarta projects as a reference for the "right" way to setup a project (with continuous integration, tests, documentation for new developers, etc.)
One thing I wish that I would have done is to blog everything I learned in a major free hosted blog server (hosted by a large company that would hopefully not go away anytime soon). If you do this though, you might just want to keep records as text files while you are working and then blog them later. But don't blog anything with company specific data in it! If your company has an internal wiki server, you could use that for private documentation usually, or worst case store it in text files only, and then be sure to periodically make a local copy of it and all of your code that you write to have a personal copy, if you can. Early as a developer you'll need to provide source to places you apply for work, and it is good to have your work for your own purposes as well.
I once got an article deleted that was fairly obscure, but relevant and worth a place in wikipedia nonetheless. After several months someone nominated it for speedy deletion, and it got deleted! I disputed the deletion with an explanation of why it was relevant, and got it reinstated; at the same time, I left a comment on the page's discussion (a reply back to the guy that deleted it) very professionally and unemotionally defending the article. Although I could tell he was a little peeved, he ended up letting it go and has since not tried to delete it or any other of my further articles.
And many schools/universities have their material online. Try Google.
Those with thin wallets and empty pocketbooks can get a decent education as long as they have the time, the will, and with free access to a computer (via public library for example).
You shouldn't be offended by companies that decide to test their future employees. Quite the opposite actually. If they don't want to test then it might be because they don't have time to test you, which could be a really bad sign. For example, Google tests it's employee's (via technical interview) quite thoroughly. I consider a paper/online test just another part the technical interview, and have been happy to fill one out or write the code/project necessary to complete the question.
Yeah, I remembered when this happened...
First the hardon collider, then the antimatter stabilized the wormhole, then the demons, then I used the BFG 9000. Case closed.
Slashdot Mirror
RAID???!!! Aaaaaaah! (Drive dies.)
Just asking... It seems like it would fit the definition:
"Rocket-propelled vehicle and payload (the frog is its own vehicle and payload, and can be rocket-propelled via bottle rocket) that takes off vertically (frogs jump), climbs to a defined altitude (frogs can jump consistently to a defined height), flies for a pre-determined amount of time (frog stays in the air a while), and then land vertically on a target (a lilypad) that is a fixed distance from the launch pad (1.5 feet away). After landing, the vehicle must take off again within a pre-determined time, fly for a certain amount of time and then land back on its original launch pad (frogs do this)."
I'm definitely not trying to rationalize inaction. I've become quite tired of being accustomed lately to others' failure, disorganization, and lack of accountability, which might be summed up as "inaction".
And I agree with you. Backing up data, whether it be for email or any type of service/application, is critical for the organization. Caching can be very important too, but just so I understand...
Doesn't a cached mail solution also present its own fault-tolerance issues?
For example, lets assume that you always send users to the name of the mail service provider (myfinancialinstitution.com) backed by multiple names pointing to geographically distributed mail servers that cache and back up GMail. Now your macro point of failure is your own service. You could have DNS issues/network issues, server issues, DB issues, etc. that will still come back to bite you.
That is the problem in my mind. While trying to setup additional fault tolerance, you're conceivably setting up other lines of dominoes to the side of the other GMail lines of dominoes that could fall. So hopefully when your dominoes go down en masse (as GMail did, and as each service/network almost inevitably will at some point), you can easily repoint that name (hopefully still reachable) so that the 100,000 users can be rerouted to GMail (assuming you're using the same ports, settings, etc.). And hopefully the organization was smart enough to allow and suggest their users be able to work remotely, in case the network outage affects the workplace. Also we'd assume the organization hasn't tied their users so tightly to the internal network/services that they can work when almost completely isolated from it. :)
Anyway, you are right. And apologize, because this is all just in good fun for me.
Unfortunately, Slashdot doesn't let you post Arabic characters, but it is the rightmost word in the following page: http://www.howtosayin.com/say/arabic/oops+I+did+it+again.html
(literally it means "pardon")
But seriously, poor LittleBigPlanet. What a tough break. That has to be expensive.
Good point, but anything can fail really. You can add layer upon layer of redundancy and fault tolerance, and then someone explode a nuclear bomb that takes out the right spots in the world's network that totally disables your services. Still, as you say, fault tolerance on a macroscale cannot be ignored. And I'm not saying that GMail would be a great way to outsource email service for a large critical enterprise, but it certainly is fine for the most part for some some large organizations, even if this particular failure is obviously not acceptable and something needs to be done to avoid it in the future. Critical services go down, and people get fired. Organizations learn and grow. Life goes on.
GMail is not really a single point of failure, since they have redundant servers, routers, databases, etc. etc. Although this outage definitely exposed something that wasn't fault tolerant enough. Only a small percentage of companies use more than one mail provider. Most use their own internal one, and more often than not, it is not setup as well as GMail. On top of all of that my organization recently had a full day's email outage, and we'd be having issues for weeks because of a migration. I know of another company locally that lost a good bit of their email recently. Problems like that are normal, and you can't just say people shouldn't be using GMail.
They're going to losing their iPhone/iPod at the frat party, so why not provide them a barf bag to save the rug in the dorm room when they return?
Display the count in binary and you're all set!
Complex Mail Transfer Protocol - coming soon!
Forget Linux, throw away all electronic devices, and follow these handy tips:
1. Preferably find a wife/husband related to you (the closer the better, because you can trust your blood kin more, but avoid anything closer than 3rd cousins if possible).
2. Squat on a large remote property you don't own (preferably somewhere considered by other folk to be inhabitable).
3. Have 10-50 kids (more than that and you might just be inviting mutiny).
4. Teach kids to how to hunt, fish, and guard the perimeter of the property you're squatting on.
5. Please note that aluminum foil around the head isn't safe anymore because of darn nanotechnology, in fact nothing is completely safe. But making everything from nature is as safe as your going to get, so make everything from all natural materials that you find and grow yourself.
6. Stop reading slashdot. They watch people that read slashdot.
SunOS/Solaris had its heyday already. It is unlikely that it will gain much more share of the market than it already has. While OS X will continue to gain more share on the desktop, Linux will probably end up dominating the server side. But Solaris won't go away.
You'll be a better developer if you work under good developers, challenge them, and seek to understand why they do the things they do.
In addition, look at major open-source projects in the language you'll be using if they exist. For example, as a Java developer, I often looked at Apache Jakarta projects as a reference for the "right" way to setup a project (with continuous integration, tests, documentation for new developers, etc.)
One thing I wish that I would have done is to blog everything I learned in a major free hosted blog server (hosted by a large company that would hopefully not go away anytime soon). If you do this though, you might just want to keep records as text files while you are working and then blog them later. But don't blog anything with company specific data in it! If your company has an internal wiki server, you could use that for private documentation usually, or worst case store it in text files only, and then be sure to periodically make a local copy of it and all of your code that you write to have a personal copy, if you can. Early as a developer you'll need to provide source to places you apply for work, and it is good to have your work for your own purposes as well.
It's true. Many developers (including myself) dream of quitting and becoming lawn maintenance professionals.
I once got an article deleted that was fairly obscure, but relevant and worth a place in wikipedia nonetheless. After several months someone nominated it for speedy deletion, and it got deleted! I disputed the deletion with an explanation of why it was relevant, and got it reinstated; at the same time, I left a comment on the page's discussion (a reply back to the guy that deleted it) very professionally and unemotionally defending the article. Although I could tell he was a little peeved, he ended up letting it go and has since not tried to delete it or any other of my further articles.
Good info on Stanford. In addition, don't forget that MIT has had many more courses available for a good while now:
http://ocw.mit.edu/OcwWeb/web/courses/courses/index.htm
And many schools/universities have their material online. Try Google.
Those with thin wallets and empty pocketbooks can get a decent education as long as they have the time, the will, and with free access to a computer (via public library for example).
The best reference site for all programming languages is...
http://google.com/
You shouldn't be offended by companies that decide to test their future employees. Quite the opposite actually. If they don't want to test then it might be because they don't have time to test you, which could be a really bad sign. For example, Google tests it's employee's (via technical interview) quite thoroughly. I consider a paper/online test just another part the technical interview, and have been happy to fill one out or write the code/project necessary to complete the question.
Top ten reasons COBOL is coming back...
#10 - ERROR 41!
#9 - Because I love the dichotomy of "STOP RUN."
#8 - Because my project manager said "I once wrote a 4000 line program in COBOL" and I want to see his ass write one!
#7 - COBOL? I thought you said "Cue ball".
#6 - Variable names are just too long these days.
#5 - I miss punch cards.
#4 - Because we have to build Dave from 2001. (We're 7 years behind schedule because of all of that year 2000 crap!)
#3 - Starbucks is closing which means no more Java!
#2 - Because Arnold demands it!
and the #1 reason ...
1. Because COBOL is an anagram for BCOOL!
Yeah, I remembered when this happened... First the hardon collider, then the antimatter stabilized the wormhole, then the demons, then I used the BFG 9000. Case closed.