Success in a big organization has a lot to do with making friends with not just high level people (obvious), but also with people that manage paperwork for a living. Most of them are used to having people scream at them and give them a hard time. They build up a programmer-like cynicism since so many dismiss their contributions. *BE NICE TO THEM*
Taking care of them, writing them nice emails, taking 5 minutes out of your day to say "how are you doing?" is worth more than you can ever imagine. When I need anything out of the system, I now have "go to" folks that will help me navigate the system, exploit details that are not commonly known, and even bend the rules a bit.
When I cash in a favor I make sure and replenish the deed by dropping off donuts for the team, contributing to birthday gift funds, etc. Believe it or not, most of these folks are actually nice people that are trying to navigate the same mess you are. Be nice to them and you'll get far "in the system".
With respect to what another poster said about protect yourself -- that's true no matter how big or little the company. Make sure you take care of yourself. A good relationship with all the staff is a good way to accomplish that.
register.com is one of them. They are far more expensive than a lot of others ($35/yr with no discounts until you start renewing for more than 3 years) but they'll host your DNS as part of the package if you want. For a few bucks more they'll host a few static web pages too. They have automatic renewel support, send reminders well in advance, and have fantastic telephone support. I put $210/yr into their coffers with my domain names, but it is well worth it. I've been hassle free ever since I made the switch a few years back.
Then use a compression accelerator like NetScaler (www.netscaler.com). I've seen it used on similarly large sites to handle load balancing and acceleration. The servers don't have to do squat and you don't have to change the app. For large enough sites, the savings should more than make up for the cost of the box.
I think most of my posts to Slashdot begin with "It Depends..." =)
Answering this... It Depends...
What is your cluster's tolerence to failure? If a node can fail, then you have the option of buying a lot of cheap hardware and replacing as necessary. This is the way that most big web farms work.
What is your cluster machine requirements? Do you have heavy I/O? Does cache memory matter? Do you need a beefy FSB and 64G of RAM per node? You may find that spending $3000/node ends up being cheaper than buying three $1000 nodes because the $3000 node is capable of processing more per unit time than the three $1000 units are.
What is your power/rack cost constraint? Google is an invalid comparison simply because of their size. They boomed when a lot of people were busting and co-lo's were hungry for business. I'd bet they have a song of a deal in terms of space, power, and pipe. You are not Google and I doubt you have a similar deal. Thus, you may find that there is a middle ground where it is better to get a more powerful machine to use less rack space/power.
In the end, you have to optimize between these three variables. You'll probably find that the solution, for you specifically, is going to be unique. For example, you may find that: Node failure is an option since the software will recover, power/rack costs are sufficiently high that you have to limit yourself, and CPU power with a good cache is crucial, but I/O isn't. This means getting a cheaper Athlon based motherboard with so-so I/O and cheesy video is a good choice since it frees your budget for a fast CPU. Combine with the cheapest power suppy the systems can tolerate and PXE boot and you have your ideal system.
Updates would be important, so we'd have to organise a way to continually maintain the digital textbook, keeping it current, while keeping in mind the teachability of the text..
Being in the middle of a 4th edition update of my own book on Linux, I can't begin to describe the amount of work needed to maintain a full book. Giving a single chapter sufficient depth to make it useful and interesting is typically about 20-30 hours of work depending on how efficient of a writer you are. Keeping a text up to date, especially one on current technology, requires a serious update every 9-12 months. Subjects that we would consider "fundamental" like the idea behind a computer can still age and require refreshing.
I don't mean to be a killjoy, but I do want to share a realistic view on the process of writing and maintaining a textbook. If you decide to go forward with the project, I wish you the best of luck. I do hope you succeed.
Depends which Samoa the author is referring to. American Samoa (the eastern islands) are a US Territory. The independant state of Samoa has its own government, but given its proximity to the American Samoa and its New Zealand roots, I would guess that it has a similar copyright law.
A more accurate question is whether it is observed and/or enforced. For a small classroom, I doubt either is an issue.
There are a lot of web sites that have sections for teaching beginners how to do many of the basics that you speak of. If you're using Microsoft software, be sure to check out the Office section of their web site -- there are a wealth of materials there. Assuming you have a small enough class, collecting articles based on the course outline and putting them into a series of PDFs that can be easily shared and printed amongst your students should provide the beginners level material.
AFAIK, there isn't anything free in the formal courseware world for the kind of content you are looking for. The market for beginners books, guides, and lessons is staggering -- you'll be pressed to find a good quality beginners coursebook that doesn't cost a pretty penny. The short web articles on the other hand are plentiful and should hopefully be enough to get you and your students going.
If the purpose of the course is to give immediate knowledge that they can take to a job and say "See, I know JavaScript!" then stick to books that you can find at the local bookstore (e.g., the "Teach Yourself in 21 Days" variety). There is nothing wrong with them for what you need to do with the content and what your students expect.
If the intent is to use JavaScript as a kind of stepping stone class to other higher level content or to really get into the depths of JavaScript (it is, after all, a full blown programming language that is quite capable), using a series of articles from web sites would serve you well for getting them bootstrapped and functional, but a more traditional text that teaches functional programming will make them more productive in the long run.
Whatever you choose, be sure you take a careful evaluation of the content and be sure to match it up with your course outline. Use the content of the book to reinforce or provide additional reference material for the lectures. (Please don't just lecture the contents of the book!)
Finally, keep project ideas in mind. You'll need a few simple project ideas that reinforce a particular chapter/lesson from week to week. Plan for a "big" 2-3 week project at the end of the course that brings all of their skills together and can serve as a reference project on their resume.
Outsourced email is actually a pretty good business. To clarify, this is not funnyname@standard-addy.com, but full blown email using the company's domain name. From an outsider's point of view, there is no difference between outsourced service and a company housing their own mail server.
The beneits? Someone else takes care of the hardware, software licenses (if applicable), disk, backups, maintenance, and 24x7 availability. For a small company with no IT staff, this is great -- someone else manages the web site, someone else manages the mail server, and a local VAR with a maintenance contract comes by and takes care of the file/print server from time to time. A maintenance contract can be as little as a few hundred dollars a month which is substantially cheaper than keeping someone on staff. The backups get automated and the receptionist is told to swap tapes daily.
For a larger organization, the value can easily mean the savings of a headcount. The loaded cost of a moderate to strong IT staffer on the west coast is easily between $80-$100k/yr plus the hardware and software costs associated with the mail server itself. If you can outsource all of that for $30-$40k/yr to someone else, you've just saved a lot of money and headache.
Agreed. Peaks and valleys are part of the deal. Pre-IM, I once monitored mail traffic across the course of a day. I noted spikes at around 8:30-9:30a (morning mail glut), 11:45-12:15 (what are you doing for lunch?), and of course, 4:45-5:00 amongst students (hey, what's up for tonight?). The same concept holds true for web apps.
Going back to what you originally said though, spikes and valleys are all relative. A spike for google.com is very different than a spike for my little web server...
This is a great point. One note to add -- when looking at your monthly logs, don't get too amazed at yourself for having 1 million hits. Take a moment and break it down into per-second numbers. You'll be surprised... 1 million hits/mo assuming a normal distribution is only about 1 hit every 2-3 seconds. Not exactly a big load unless each hit generates a huge complex page that sucks down your bandwidth. Figuring a normal 8-5 day M-F, that goes up to 2 hits/sec.
Suddenly that 1 million hits/mo isn't so daunting.
Apache benchmark is cool and all, but it isn't nearly sophisticated enough to generate complex traffic and emulate real user behavior with the right headers, etc. You can apply some mad-scripting skills around it and customize it a touch, but that's a slippery slope to doing a lot of work. If all you need is load generation for a single URL, Apache Benchmark (ab -- it compiles with a standard distro of apache) works as does http_load (www.acme.com), webbench (www.webbench.com), and WAST (Microsoft Web Application Stress Tool). There are many others as well.
If you need something more sophisticated, be prepared to shell out money. This means something like LoadRunner (Mercury software) or the like. There are other vendors that do this too, so shop around.
If you only need simple load generation and you're doing this from windows, I prefer WAST if you need to tweak the data from some scripts easily since it dumps all of its output into an Access database. If you're doing it from Unix, either ab or http_load will do. http_load also does SSL, I don't recall if ab does.
You don't mention if you're on the applications side of the world or the network, so I'll cover a little about both.
1. If you're on the app side, make friends with the network side and vice versa. To understand web site management and acceleration, you will need to know about both parts. Making peace with the other team is crucial to a successful site.
2. If you are on the app side, start thinking about concurrency from the start. You're going to have not 2-3 users at the same time, but more like hundreds if not thousands. This means that you can't do things like lock up tables and the like in the database. If at all possible write your application so that users don't need to come back to the same server to track their session information. Make sure each request is tracked quickly and easily. Also, differentiate your static content from the dynamic content -- you'll eventually want to cache the static content and life will be easier with static objects being served out of a known location. And please... please, please, please... make sure your app generates clean HTTP headers. Set your cache controls correctly, don't duplicate headers, don't be a smart-ass with your headers. Just use clean headers. ASSUME that there will be proxies between you and the client. ASSUME that you will not be able to control all of them.
3. Don't forget about megaproxies. Depending on the nature of your site, you're going to have a ton of your users coming from a small handful of addresses. (e.g., AOL) While some megaproxies have fixed the issue of a single user coming out of multiple proxy servers, all have not. This means anything that you use for client IP persistence is broken.
4. Client IP addresses... don't assume you have them. Don't assume they represent a unique user. They don't. Many load balancers/web accelerators also need to act as proxy and will replace the client IP address anyway. (Don't stress about logging -- any reasonable one will insert the client IP address in a HTTP header that you can extract like X-Forwarded-For:)
5. Peak load on your web servers. Apache can go fast, scale, blah blah blah... my ass. It's not the web server or operating system that is going to determine your peak performance. It is your application itself. Be prepared to fess up to the reality that your application peak performance is not going to be hundreds or thousands of requests per second unless you go insane with the optimization. (e.g., write your application into the web server and embed the whole thing into the kernel, etc.) Assume you're more likely going to get a few dozen requests/sec per app server. Keep that in mind as you plan server purchases and scaling.
6. HTTP request does not equal TCP connection. Don't assume that. With HTTP multiplexing like the stuff that Netscaler does (web accelerator), you're going to see most of your requests coming out of a small handful of TCP connections. Make sure your application supports that. Even if you don't use a web accelerator, browsers will do that do. Don't cheat and force the connection closed on every HTTP request, your web server will crap.
7. This is related to 6, but don't forget that web connections are very short lived compared to what the original designers of TCP were thinking about. As a result, you're going to run into cases where you run out of epheral ports (netstat -an will show a ton of ports in TIME_WAIT) even though your machine is idle. This is why HTTP Multiplexing is important -- you don't want a lot of connection churn. Yes, you can tweak your OS settings so that TIME_WAIT expires quickly, but that isn't going to help your overall performance. (TCP connection setup/teardown is a huge burden on a HTTP request that may only span a few packets...)
8. Look into HTTP acceleration technology from the get go. I've used several different brands and I've found Netscaler's to be the best. They are crazy fast and capable boxes that have a ton of features (like the HTTP multiplexing, SSL acceleration, HTTP compression, web
Give them each a book as a present to start with -- it gets the juices going and it also gives them a place to reference. This lets you focus on concepts and lets the book serve as a memory of what they are learning.
A great book to start with is Linux Administration: A Beginners Guide. Good stuff. Especially helpful for administrators moving from Windows power user to Linux administrator.
What? Your cubical, computer, the electricity, benefits, building, internet access, manager, and administrative staff (e.g., that person that sits at the front desk screening calls so you don't have to), doesn't cost money? What about packaging, artwork for the box, shipping, and distribution? Yeah, they all cost money too. It's called loaded cost. Your salary is a big chunk of it, but the total cost is greater than your salaries alone.
Simple example, that hard plastic bezel that goes on the front of a 1U appliance? Designer capable of producing the mechanical drawings for the manufacturer: $15k, cast for plastic molding: $15-20k. That's just the dollar cost for those people to do it -- there is a cost of the people involved within the company to get it done. They had to price it out using phones, from their cubicals, get paid during that time, etc. Loaded cost before the first $1.00 bezel gets stamped? About $40k.
Software is of course cheaper, however it still needs a box and packaging. Since it doesn't make sense for a software company to employee people who can do this full time, this gets contracted out. A small design project to design, layout, and generate the mechanicals for the box manufacturer will probably go for about $10k. The box manufacturer will require an upfront commitment for a certain number of boxes before they'll make them. So figure in another $5-10k up front. You gotta store those boxes somewhere (inventory), so make sure you have space for that. Then you need a manual to go with the game. It may be a simple enough game to only need a leaflet, but that still needs to get written. A project like that will cost a few thousand dollars plus the upfront printing commitment. Need any plastic molding to hold all of this in so it doesn't rattle around? Yeah, add money to that too. By the way, programmers need to be busy writing code -- so someone else has to put the CD and manuals into the plastic and put that into the box for shipping. The CD! Almost forgot that... Artwork, jewel case, artwork that goes on the CD itself... You gotta make a master for the CD which for high production runs is $1500. Thankfully those per-unit costs drop a lot after that. But then you need to commit for some number up front. Better make sure that storage that you got the empty boxes has some extra space.
Great -- you've made the game and the box looks good. Still haven't spent $250k? Oh... wait... there's telling people about it. Still need the programmers designing the next game so there better be someone doing the marketing for the product. Posters, artwork, in store displays, bugging magazines to review the product, doing events where the gamers are so you can show them you have a game. Low budget impulse buy kind of game? It wouldn't hurt to have an ad and be mentioned in Parenting Magazine -- that half page ad is $25k for one month. Plus artwork, plus the person's time to do it.
Reseller costs? Wait... you mean that $9.95 I paid for the bargain game isn't all going to the company that made it? Try about $4-$5 at best, depending on how many distribution tiers were involved.
And that's just for a US version. Want to sell in Asia? Rinse and Repeat...
That $10k advance for your 3D beat'em'up game is a small part of the total cost to sell the thing.
Find a legit copy of MS Office for sale on ebay that's being sold for $5 and see if the seller is willing to part with it as a donation. OpenOffice isn't old enough to have a version that will run well on 4 year old hardware.
The reason is that the laptop is likely going to be used with school children that are trying to get ahead in the world and thus will eventually need to learn how to use a few real world applications. A word processor can be a relatively simple tool (only need to know how to open, save, and print to become functional) but puts the power of a typewritten letter into the hands of people that may not have easy access to typewriters. (Type written letters are far more likely to be taken seriously than a handwritten when one is asking for additional funds, access to projects, information, etc.) For younger learners, sending a typewritten letter to some other family member is a huge deal if they don't normally have access to the technology.
Powerpoint is another simple tool (low learning curve) that gives students the ability to create a simple slide deck. This is the kind of thing that allows them to practice presentation giving in front of their class. Lessons learned: how to speak in public, summerize points with an audience, read an audience, and be an effective communicator. A student that learned how to give effective presentations is well suited for going out into the bigger world and explaining why $big_corp needs to stop draining $resource. A good presentation is going to catch a lot more ears than some guy ranting without a point. Learning how to give presentations and speak in public is something that should start as young as 10-12 years old.
A good typing program (game-like) is also useful.
While it may not be the best example in ths crowd, I've seen this used in remote schools in India. Kids as young as 4-5 are starting to learn how to type and use Word. The 12 year olds give presentations that would put most adults to shame. When they hit the age where they can represent their communities, their presentations and public letters are 100x more likely to sway public opinion about policy that affects them.
IBM is far from irrelevant. Global Services is a $40B business unit with the ability to make and break technologies on a whim -- and they don't just pick/bias IBM built technologies either. They pick what's right for the job and the customer its going to.
The IBM technology arm continues to innovate a lot of core technologies. They aren't big and visible to the general public, but they do affect how the world spins. You aren't the world's 17th largest company and become "irrelevant."
First off, your employer has workers comp insurance. They pay a regular premium for exactly this reason -- make their premium worth it.
Second, the hoops are there to stop fraud. Yes, it's frustrating. But it's there because enough jackasses said that they were really sick and milked the system for a ton of money when in reality they weren't. So now the employer wants the option to send you to one of their doctors that they trust rather than your default doctor. Once their doc blesses it, you'll be back to normal with respect to process.
Third, and this is the most important: DON'T GET SCREWED WITH CARPAL. Without your wrists, you have no job. Period. You don't do your employer any good and you certainly don't do yourself any good. For a few hundred in doctors visits and a few hundred in getting the right equipment (keyboards, etc.), your employer keeps you working. It's substantially cheaper than losing you to disability. When you're on disability, he has to keep your job open, pay your benefits, AND not get any of your work.
Workers comp comes with a stigma when it's abused. Don't abuse it and you'll be fine.
Think in terms of the user -- not as a developer
on
Documentation Strategies?
·
· Score: 4, Insightful
Think about this project in terms of the person reading the documentation and using the product. DO NOT THINK LIKE A DEVELOPER. Yes, that's hard. But it is important. Developers are quick to point out little cool things but then fail to explain the bigger picture because it seems "obvious". Nothing about your system is obvious to another person that hasn't been swimming in it for as long as you have.
When thinking like the user, consider the flow of how they will approach it. What are the steps to get started? What are the major features they need to understand? How do the different components interact?
Include lots of examples. Use tools like Photoshop (Essentials is fine) to highlight parts of the screen and bring them out.
Use simple language. If your command of written english isn't the strongest, plan on getting a copy editor to review your work. Also plan on having someone outside of the product read the manual and try everything in it.
DOUBLE CHECK EVERY EXAMPLE, COMMAND, AND REFERENCE. Nothing sucks more than a manual that has incorrect examples.
Look at other documentation that has worked well for you in the past. Also look at popular tools in the same competitive space and see how they do things. Don't neglect another company's manual because the "company and their products suck." If there are a lot of people that use that product, they'll be familiar with that style of documentation. Consistency with things that your users are already familiar with will go a long way.
Be consitent across the entire document. Use the same examples, IP addresses, documents, names, etc. everywhere. Be consistent with your use of italics, bold, and courier print. Keep in mind that arial 10pt is about the same size as Times 12pt which is about the same size as courier 10 pt.
Consider what the final product will look like on screen as a pdf and on paper when printed. If your product does will, manuals will get printed.
Keep chapters in separate files. Makes them easier to edit and protects you from corrupted files. It's always easier to assemble a few files into a bigger file than it is to break apart a huge file.
Has anyone done a modern version of 101 BASIC Games?
That said, you may want to start by working with some realistic expectations. Does you son understand the sheer amount of work necessary to do the games that he probably plays? Does he understand that the first few games that he does are likely to be very simple in nature? When my wife started learning how to program, she was an avid user and excited about the possibility of becoming a programmer. She was dissapointed at how a full day of working could only produce trivial little DOS programs that were nothing like the apps she used. Unfortunately I wasn't able to better set her expectations and she ended up frustrated with programming and hasn't seriously looked back at it. Today she has a much better view of what it takes, but that first time experience still keeps her from making any serious headway...
As for ideas, start with simple things first. E.g. simple screen saver type animations on the screen that can be brute forced. This gives good visual feedback without concern over input processing or timing. Move on to simple role based games where the program can wait for input from the user before acting on it. E.g., board games (connect-4, tic-tac-toe, etc.), simple D&D type games, etc. It's probably worth getting WarGames on DVD to show that real systems/big games did look like that at one time. If you have an emulator of a 8bit PC (Commodore/Apple2), try to show some older games that were interactive like that. From there, look into adding graphics (e.g. Myst). At this point, he'll probably be ready for making the leap to a action game that requires concern for real time keyboard/mouse/joystick input and live screen updates.
Being a dad, I'm sure I don't need to tell you this, but be ready to spend a lot of time helping him with it. Those first few debugging sessions are going to be really frustrating...
You've never graded programs, have you? When a professor (or more often, a TA) has 60 programs turned in, each easily being hundreds if not a thousand lines long, there is no way the person is going to make any serious headway on the matter. At best, the grader can guess about what students tend to group together in class and use that as a heuristic. Of course if there are three sections, each with 30 students, and there are friends between sections... well, forget it.
The (very, very sad) reality is that there is a disguesting amount of cheating that is happening in Computer Science programs. It is a genuine concern of professors to have to worry about this. The fact there there is enough demand to warrant a company to check on it should tell you something.
The year before I became a TA for an operating systems course, my school had to give up on NACHOS (Not Another Completely Heuristic Operating System) as part of the cirriculum. There were too many full source implementations sitting on the net that were getting turned in as homework assignments. I ended up changing the program to use Linux with assinments revolving around kernel hacking. The sad thing is that I think the students learned less than if they had used NACHOS since NACHOS allowed them to experience all facets of the operating system from the ground up versus the Linux assignments that had to be a lot more focused. (The lessons I learned from having done NACHOS in '94 I still use today.)
The assertion that cheat checkers don't work well with homework assignments is true for small enough units of code, the kind found in introductory courses. Even then, you'd be surprised at how different 30 people can write the same simple program. Cheat checkers used in those classes generate several false positives per assignment that usually get human review. One match between another student is usually tagged as a "whatever", the second gets noticed... three or four in a row of the same two or three students and you have a real problem. Legit submissions that hit false positives usually match different students on the second and third try. By the time assignments get into second year CS programs, assignments are several hundred lines long and usually are sufficiently different to not get matched at all from different implementations. Third year assignments and any matches are immediately suspicious.
In general, professors use cheat checkers as a tool to identify trends. Final decisions are made by the professors themselves -- they're CS grads, they know that cheat checkers aren't perfect. A few hits and you usually get a meeting with a prof with a few questions. If you know the material and can explain the code, you're fine. You'd be amazed at the number of people that get into that situation and can't explain the code one bit.
In the end, the real losers in this are the students that don't cheat. Not having mastered the art of deception and taking others people work and claiming it their own, those who have been honest end up not making as much money or getting as far with their careers. Those that have mastered deception are the ones that become your Pointed Haired Bosses and lie to you. Funny how that works...
My wife and I IM all the time, even when we're 10 feet away. Within the house, IM messages tend to be "check out this link" or "hey, it's dinner time." Real conversations don't happen over IM within the house for the very reason several folks pointed out -- it's silly and it isn't a real conversation.
An amusing side effect is that it becomes possible to improve your writing and typing skills with IM so long as both parties don't tolerate IM shorthand. i.e., no "u" or "ur" crap. A friend of mine recently learned about the wonders of IM when his fiance worked across the country for a few months. His typing skills really improved as did his written english. IM actually forced him to become an effective communicator. Granted, it's rare for that to happen, but it can if everyone chatting doesn't tolerate broken english. =)
Bottom-line -- IM isn't a substitute for conversation and when I have kids they won't be allowed to get away with not talking, but it does have a place and it can be useful.
This may be hard for some to fathom, but try this: turn it off. No really. I mean it. When I need to work, I minimize email, go "invisible" on IM, and let voicemail pick up the phone. My cell phone has caller ID so I can ID my wife and know to pick up the phone.
All of these technologies have a way of being turned off and queueing messages for you. Use it. When you're ready for a break or it's just that time again, process them in bulk and get them over with. When I was programming, I only processed email 2-3 times a day (morning, right before lunch, and towards the end of the day) and this worked very well. Having a gig in marketing land has changed my job requirements where I'm actually judged by how often I interact with the sales team and customers so I check mail more often -- but, when I need to get a document written up or read and comment on something else, I minimize it all and focus.
One last note about IM -- have strict rules about IM. I don't socialize over IM when I'm working. I tell friends that are on my buddy lists to not expect a response during typical working hours if they just want to chat. I won't respond. If you want to send a social comment, send it via email to my personal mailbox and I'll get to it when I've got time to socialize.
Don't worry about real time updates. Really, it's just not that important. If your family wants to hear from you to know that you're alive, get a cheap calling card and give'm a ring.
For the purpose of keeping a journal (which is a very respectable thing to do on a trip like that), take your laptop and your digital camera and use it for dumping pictures and taking notes. No internet access. No email. No games. Do nothing on your laptop that you can do at home.
I recently took a trip through California. The laptop rules were simple: dump pictures onto it and jot down notes. That's all. And you know what -- I loved it. My wrists felt better, my head was less congested, and I spent enough time checking out things that I normally don't get to see. You know... a vacation...;-)
Slashdot Mirror
Success in a big organization has a lot to do with making friends with not just high level people (obvious), but also with people that manage paperwork for a living. Most of them are used to having people scream at them and give them a hard time. They build up a programmer-like cynicism since so many dismiss their contributions. *BE NICE TO THEM*
Taking care of them, writing them nice emails, taking 5 minutes out of your day to say "how are you doing?" is worth more than you can ever imagine. When I need anything out of the system, I now have "go to" folks that will help me navigate the system, exploit details that are not commonly known, and even bend the rules a bit.
When I cash in a favor I make sure and replenish the deed by dropping off donuts for the team, contributing to birthday gift funds, etc. Believe it or not, most of these folks are actually nice people that are trying to navigate the same mess you are. Be nice to them and you'll get far "in the system".
With respect to what another poster said about protect yourself -- that's true no matter how big or little the company. Make sure you take care of yourself. A good relationship with all the staff is a good way to accomplish that.
register.com is one of them. They are far more expensive than a lot of others ($35/yr with no discounts until you start renewing for more than 3 years) but they'll host your DNS as part of the package if you want. For a few bucks more they'll host a few static web pages too. They have automatic renewel support, send reminders well in advance, and have fantastic telephone support. I put $210/yr into their coffers with my domain names, but it is well worth it. I've been hassle free ever since I made the switch a few years back.
Then use a compression accelerator like NetScaler (www.netscaler.com). I've seen it used on similarly large sites to handle load balancing and acceleration. The servers don't have to do squat and you don't have to change the app. For large enough sites, the savings should more than make up for the cost of the box.
I think most of my posts to Slashdot begin with "It Depends..." =)
Answering this... It Depends...
What is your cluster's tolerence to failure? If a node can fail, then you have the option of buying a lot of cheap hardware and replacing as necessary. This is the way that most big web farms work.
What is your cluster machine requirements? Do you have heavy I/O? Does cache memory matter? Do you need a beefy FSB and 64G of RAM per node? You may find that spending $3000/node ends up being cheaper than buying three $1000 nodes because the $3000 node is capable of processing more per unit time than the three $1000 units are.
What is your power/rack cost constraint? Google is an invalid comparison simply because of their size. They boomed when a lot of people were busting and co-lo's were hungry for business. I'd bet they have a song of a deal in terms of space, power, and pipe. You are not Google and I doubt you have a similar deal. Thus, you may find that there is a middle ground where it is better to get a more powerful machine to use less rack space/power.
In the end, you have to optimize between these three variables. You'll probably find that the solution, for you specifically, is going to be unique. For example, you may find that: Node failure is an option since the software will recover, power/rack costs are sufficiently high that you have to limit yourself, and CPU power with a good cache is crucial, but I/O isn't. This means getting a cheaper Athlon based motherboard with so-so I/O and cheesy video is a good choice since it frees your budget for a fast CPU. Combine with the cheapest power suppy the systems can tolerate and PXE boot and you have your ideal system.
Best of luck.
Updates would be important, so we'd have to organise a way to continually maintain the digital textbook, keeping it current, while keeping in mind the teachability of the text..
Being in the middle of a 4th edition update of my own book on Linux, I can't begin to describe the amount of work needed to maintain a full book. Giving a single chapter sufficient depth to make it useful and interesting is typically about 20-30 hours of work depending on how efficient of a writer you are. Keeping a text up to date, especially one on current technology, requires a serious update every 9-12 months. Subjects that we would consider "fundamental" like the idea behind a computer can still age and require refreshing.
I don't mean to be a killjoy, but I do want to share a realistic view on the process of writing and maintaining a textbook. If you decide to go forward with the project, I wish you the best of luck. I do hope you succeed.
Cheers,
Depends which Samoa the author is referring to. American Samoa (the eastern islands) are a US Territory. The independant state of Samoa has its own government, but given its proximity to the American Samoa and its New Zealand roots, I would guess that it has a similar copyright law.
A more accurate question is whether it is observed and/or enforced. For a small classroom, I doubt either is an issue.
There are a lot of web sites that have sections for teaching beginners how to do many of the basics that you speak of. If you're using Microsoft software, be sure to check out the Office section of their web site -- there are a wealth of materials there. Assuming you have a small enough class, collecting articles based on the course outline and putting them into a series of PDFs that can be easily shared and printed amongst your students should provide the beginners level material.
AFAIK, there isn't anything free in the formal courseware world for the kind of content you are looking for. The market for beginners books, guides, and lessons is staggering -- you'll be pressed to find a good quality beginners coursebook that doesn't cost a pretty penny. The short web articles on the other hand are plentiful and should hopefully be enough to get you and your students going.
Best of luck.
If the purpose of the course is to give immediate knowledge that they can take to a job and say "See, I know JavaScript!" then stick to books that you can find at the local bookstore (e.g., the "Teach Yourself in 21 Days" variety). There is nothing wrong with them for what you need to do with the content and what your students expect.
If the intent is to use JavaScript as a kind of stepping stone class to other higher level content or to really get into the depths of JavaScript (it is, after all, a full blown programming language that is quite capable), using a series of articles from web sites would serve you well for getting them bootstrapped and functional, but a more traditional text that teaches functional programming will make them more productive in the long run.
Whatever you choose, be sure you take a careful evaluation of the content and be sure to match it up with your course outline. Use the content of the book to reinforce or provide additional reference material for the lectures. (Please don't just lecture the contents of the book!)
Finally, keep project ideas in mind. You'll need a few simple project ideas that reinforce a particular chapter/lesson from week to week. Plan for a "big" 2-3 week project at the end of the course that brings all of their skills together and can serve as a reference project on their resume.
Best of luck.
Outsourced email is actually a pretty good business. To clarify, this is not funnyname@standard-addy.com, but full blown email using the company's domain name. From an outsider's point of view, there is no difference between outsourced service and a company housing their own mail server.
The beneits? Someone else takes care of the hardware, software licenses (if applicable), disk, backups, maintenance, and 24x7 availability. For a small company with no IT staff, this is great -- someone else manages the web site, someone else manages the mail server, and a local VAR with a maintenance contract comes by and takes care of the file/print server from time to time. A maintenance contract can be as little as a few hundred dollars a month which is substantially cheaper than keeping someone on staff. The backups get automated and the receptionist is told to swap tapes daily.
For a larger organization, the value can easily mean the savings of a headcount. The loaded cost of a moderate to strong IT staffer on the west coast is easily between $80-$100k/yr plus the hardware and software costs associated with the mail server itself. If you can outsource all of that for $30-$40k/yr to someone else, you've just saved a lot of money and headache.
Agreed. Peaks and valleys are part of the deal. Pre-IM, I once monitored mail traffic across the course of a day. I noted spikes at around 8:30-9:30a (morning mail glut), 11:45-12:15 (what are you doing for lunch?), and of course, 4:45-5:00 amongst students (hey, what's up for tonight?). The same concept holds true for web apps.
Going back to what you originally said though, spikes and valleys are all relative. A spike for google.com is very different than a spike for my little web server...
This is a great point. One note to add -- when looking at your monthly logs, don't get too amazed at yourself for having 1 million hits. Take a moment and break it down into per-second numbers. You'll be surprised... 1 million hits/mo assuming a normal distribution is only about 1 hit every 2-3 seconds. Not exactly a big load unless each hit generates a huge complex page that sucks down your bandwidth. Figuring a normal 8-5 day M-F, that goes up to 2 hits/sec.
Suddenly that 1 million hits/mo isn't so daunting.
Apache benchmark is cool and all, but it isn't nearly sophisticated enough to generate complex traffic and emulate real user behavior with the right headers, etc. You can apply some mad-scripting skills around it and customize it a touch, but that's a slippery slope to doing a lot of work. If all you need is load generation for a single URL, Apache Benchmark (ab -- it compiles with a standard distro of apache) works as does http_load (www.acme.com), webbench (www.webbench.com), and WAST (Microsoft Web Application Stress Tool). There are many others as well.
If you need something more sophisticated, be prepared to shell out money. This means something like LoadRunner (Mercury software) or the like. There are other vendors that do this too, so shop around.
If you only need simple load generation and you're doing this from windows, I prefer WAST if you need to tweak the data from some scripts easily since it dumps all of its output into an Access database. If you're doing it from Unix, either ab or http_load will do. http_load also does SSL, I don't recall if ab does.
You don't mention if you're on the applications side of the world or the network, so I'll cover a little about both.
1. If you're on the app side, make friends with the network side and vice versa. To understand web site management and acceleration, you will need to know about both parts. Making peace with the other team is crucial to a successful site.
2. If you are on the app side, start thinking about concurrency from the start. You're going to have not 2-3 users at the same time, but more like hundreds if not thousands. This means that you can't do things like lock up tables and the like in the database. If at all possible write your application so that users don't need to come back to the same server to track their session information. Make sure each request is tracked quickly and easily. Also, differentiate your static content from the dynamic content -- you'll eventually want to cache the static content and life will be easier with static objects being served out of a known location. And please... please, please, please... make sure your app generates clean HTTP headers. Set your cache controls correctly, don't duplicate headers, don't be a smart-ass with your headers. Just use clean headers. ASSUME that there will be proxies between you and the client. ASSUME that you will not be able to control all of them.
3. Don't forget about megaproxies. Depending on the nature of your site, you're going to have a ton of your users coming from a small handful of addresses. (e.g., AOL) While some megaproxies have fixed the issue of a single user coming out of multiple proxy servers, all have not. This means anything that you use for client IP persistence is broken.
4. Client IP addresses... don't assume you have them. Don't assume they represent a unique user. They don't. Many load balancers/web accelerators also need to act as proxy and will replace the client IP address anyway. (Don't stress about logging -- any reasonable one will insert the client IP address in a HTTP header that you can extract like X-Forwarded-For:)
5. Peak load on your web servers. Apache can go fast, scale, blah blah blah... my ass. It's not the web server or operating system that is going to determine your peak performance. It is your application itself. Be prepared to fess up to the reality that your application peak performance is not going to be hundreds or thousands of requests per second unless you go insane with the optimization. (e.g., write your application into the web server and embed the whole thing into the kernel, etc.) Assume you're more likely going to get a few dozen requests/sec per app server. Keep that in mind as you plan server purchases and scaling.
6. HTTP request does not equal TCP connection. Don't assume that. With HTTP multiplexing like the stuff that Netscaler does (web accelerator), you're going to see most of your requests coming out of a small handful of TCP connections. Make sure your application supports that. Even if you don't use a web accelerator, browsers will do that do. Don't cheat and force the connection closed on every HTTP request, your web server will crap.
7. This is related to 6, but don't forget that web connections are very short lived compared to what the original designers of TCP were thinking about. As a result, you're going to run into cases where you run out of epheral ports (netstat -an will show a ton of ports in TIME_WAIT) even though your machine is idle. This is why HTTP Multiplexing is important -- you don't want a lot of connection churn. Yes, you can tweak your OS settings so that TIME_WAIT expires quickly, but that isn't going to help your overall performance. (TCP connection setup/teardown is a huge burden on a HTTP request that may only span a few packets...)
8. Look into HTTP acceleration technology from the get go. I've used several different brands and I've found Netscaler's to be the best. They are crazy fast and capable boxes that have a ton of features (like the HTTP multiplexing, SSL acceleration, HTTP compression, web
Give them each a book as a present to start with -- it gets the juices going and it also gives them a place to reference. This lets you focus on concepts and lets the book serve as a memory of what they are learning.
A great book to start with is Linux Administration: A Beginners Guide. Good stuff. Especially helpful for administrators moving from Windows power user to Linux administrator.
What? Your cubical, computer, the electricity, benefits, building, internet access, manager, and administrative staff (e.g., that person that sits at the front desk screening calls so you don't have to), doesn't cost money? What about packaging, artwork for the box, shipping, and distribution? Yeah, they all cost money too. It's called loaded cost. Your salary is a big chunk of it, but the total cost is greater than your salaries alone.
Simple example, that hard plastic bezel that goes on the front of a 1U appliance? Designer capable of producing the mechanical drawings for the manufacturer: $15k, cast for plastic molding: $15-20k. That's just the dollar cost for those people to do it -- there is a cost of the people involved within the company to get it done. They had to price it out using phones, from their cubicals, get paid during that time, etc. Loaded cost before the first $1.00 bezel gets stamped? About $40k.
Software is of course cheaper, however it still needs a box and packaging. Since it doesn't make sense for a software company to employee people who can do this full time, this gets contracted out. A small design project to design, layout, and generate the mechanicals for the box manufacturer will probably go for about $10k. The box manufacturer will require an upfront commitment for a certain number of boxes before they'll make them. So figure in another $5-10k up front. You gotta store those boxes somewhere (inventory), so make sure you have space for that. Then you need a manual to go with the game. It may be a simple enough game to only need a leaflet, but that still needs to get written. A project like that will cost a few thousand dollars plus the upfront printing commitment. Need any plastic molding to hold all of this in so it doesn't rattle around? Yeah, add money to that too. By the way, programmers need to be busy writing code -- so someone else has to put the CD and manuals into the plastic and put that into the box for shipping. The CD! Almost forgot that... Artwork, jewel case, artwork that goes on the CD itself... You gotta make a master for the CD which for high production runs is $1500. Thankfully those per-unit costs drop a lot after that. But then you need to commit for some number up front. Better make sure that storage that you got the empty boxes has some extra space.
Great -- you've made the game and the box looks good. Still haven't spent $250k? Oh... wait... there's telling people about it. Still need the programmers designing the next game so there better be someone doing the marketing for the product. Posters, artwork, in store displays, bugging magazines to review the product, doing events where the gamers are so you can show them you have a game. Low budget impulse buy kind of game? It wouldn't hurt to have an ad and be mentioned in Parenting Magazine -- that half page ad is $25k for one month. Plus artwork, plus the person's time to do it.
Reseller costs? Wait... you mean that $9.95 I paid for the bargain game isn't all going to the company that made it? Try about $4-$5 at best, depending on how many distribution tiers were involved.
And that's just for a US version. Want to sell in Asia? Rinse and Repeat...
That $10k advance for your 3D beat'em'up game is a small part of the total cost to sell the thing.
Find a legit copy of MS Office for sale on ebay that's being sold for $5 and see if the seller is willing to part with it as a donation. OpenOffice isn't old enough to have a version that will run well on 4 year old hardware.
The reason is that the laptop is likely going to be used with school children that are trying to get ahead in the world and thus will eventually need to learn how to use a few real world applications. A word processor can be a relatively simple tool (only need to know how to open, save, and print to become functional) but puts the power of a typewritten letter into the hands of people that may not have easy access to typewriters. (Type written letters are far more likely to be taken seriously than a handwritten when one is asking for additional funds, access to projects, information, etc.) For younger learners, sending a typewritten letter to some other family member is a huge deal if they don't normally have access to the technology.
Powerpoint is another simple tool (low learning curve) that gives students the ability to create a simple slide deck. This is the kind of thing that allows them to practice presentation giving in front of their class. Lessons learned: how to speak in public, summerize points with an audience, read an audience, and be an effective communicator. A student that learned how to give effective presentations is well suited for going out into the bigger world and explaining why $big_corp needs to stop draining $resource. A good presentation is going to catch a lot more ears than some guy ranting without a point. Learning how to give presentations and speak in public is something that should start as young as 10-12 years old.
A good typing program (game-like) is also useful.
While it may not be the best example in ths crowd, I've seen this used in remote schools in India. Kids as young as 4-5 are starting to learn how to type and use Word. The 12 year olds give presentations that would put most adults to shame. When they hit the age where they can represent their communities, their presentations and public letters are 100x more likely to sway public opinion about policy that affects them.
IBM is far from irrelevant. Global Services is a $40B business unit with the ability to make and break technologies on a whim -- and they don't just pick/bias IBM built technologies either. They pick what's right for the job and the customer its going to.
The IBM technology arm continues to innovate a lot of core technologies. They aren't big and visible to the general public, but they do affect how the world spins. You aren't the world's 17th largest company and become "irrelevant."
First off, your employer has workers comp insurance. They pay a regular premium for exactly this reason -- make their premium worth it.
Second, the hoops are there to stop fraud. Yes, it's frustrating. But it's there because enough jackasses said that they were really sick and milked the system for a ton of money when in reality they weren't. So now the employer wants the option to send you to one of their doctors that they trust rather than your default doctor. Once their doc blesses it, you'll be back to normal with respect to process.
Third, and this is the most important: DON'T GET SCREWED WITH CARPAL. Without your wrists, you have no job. Period. You don't do your employer any good and you certainly don't do yourself any good. For a few hundred in doctors visits and a few hundred in getting the right equipment (keyboards, etc.), your employer keeps you working. It's substantially cheaper than losing you to disability. When you're on disability, he has to keep your job open, pay your benefits, AND not get any of your work.
Workers comp comes with a stigma when it's abused. Don't abuse it and you'll be fine.
Think about this project in terms of the person reading the documentation and using the product. DO NOT THINK LIKE A DEVELOPER. Yes, that's hard. But it is important. Developers are quick to point out little cool things but then fail to explain the bigger picture because it seems "obvious". Nothing about your system is obvious to another person that hasn't been swimming in it for as long as you have.
When thinking like the user, consider the flow of how they will approach it. What are the steps to get started? What are the major features they need to understand? How do the different components interact?
Include lots of examples. Use tools like Photoshop (Essentials is fine) to highlight parts of the screen and bring them out.
Use simple language. If your command of written english isn't the strongest, plan on getting a copy editor to review your work. Also plan on having someone outside of the product read the manual and try everything in it.
DOUBLE CHECK EVERY EXAMPLE, COMMAND, AND REFERENCE. Nothing sucks more than a manual that has incorrect examples.
Look at other documentation that has worked well for you in the past. Also look at popular tools in the same competitive space and see how they do things. Don't neglect another company's manual because the "company and their products suck." If there are a lot of people that use that product, they'll be familiar with that style of documentation. Consistency with things that your users are already familiar with will go a long way.
Be consitent across the entire document. Use the same examples, IP addresses, documents, names, etc. everywhere. Be consistent with your use of italics, bold, and courier print. Keep in mind that arial 10pt is about the same size as Times 12pt which is about the same size as courier 10 pt.
Consider what the final product will look like on screen as a pdf and on paper when printed. If your product does will, manuals will get printed.
Keep chapters in separate files. Makes them easier to edit and protects you from corrupted files. It's always easier to assemble a few files into a bigger file than it is to break apart a huge file.
Has anyone done a modern version of 101 BASIC Games?
That said, you may want to start by working with some realistic expectations. Does you son understand the sheer amount of work necessary to do the games that he probably plays? Does he understand that the first few games that he does are likely to be very simple in nature? When my wife started learning how to program, she was an avid user and excited about the possibility of becoming a programmer. She was dissapointed at how a full day of working could only produce trivial little DOS programs that were nothing like the apps she used. Unfortunately I wasn't able to better set her expectations and she ended up frustrated with programming and hasn't seriously looked back at it. Today she has a much better view of what it takes, but that first time experience still keeps her from making any serious headway...
As for ideas, start with simple things first. E.g. simple screen saver type animations on the screen that can be brute forced. This gives good visual feedback without concern over input processing or timing. Move on to simple role based games where the program can wait for input from the user before acting on it. E.g., board games (connect-4, tic-tac-toe, etc.), simple D&D type games, etc. It's probably worth getting WarGames on DVD to show that real systems/big games did look like that at one time. If you have an emulator of a 8bit PC (Commodore/Apple2), try to show some older games that were interactive like that. From there, look into adding graphics (e.g. Myst). At this point, he'll probably be ready for making the leap to a action game that requires concern for real time keyboard/mouse/joystick input and live screen updates.
Being a dad, I'm sure I don't need to tell you this, but be ready to spend a lot of time helping him with it. Those first few debugging sessions are going to be really frustrating...
Best of luck with this endeavor.
You've never graded programs, have you? When a professor (or more often, a TA) has 60 programs turned in, each easily being hundreds if not a thousand lines long, there is no way the person is going to make any serious headway on the matter. At best, the grader can guess about what students tend to group together in class and use that as a heuristic. Of course if there are three sections, each with 30 students, and there are friends between sections... well, forget it.
The (very, very sad) reality is that there is a disguesting amount of cheating that is happening in Computer Science programs. It is a genuine concern of professors to have to worry about this. The fact there there is enough demand to warrant a company to check on it should tell you something.
The year before I became a TA for an operating systems course, my school had to give up on NACHOS (Not Another Completely Heuristic Operating System) as part of the cirriculum. There were too many full source implementations sitting on the net that were getting turned in as homework assignments. I ended up changing the program to use Linux with assinments revolving around kernel hacking. The sad thing is that I think the students learned less than if they had used NACHOS since NACHOS allowed them to experience all facets of the operating system from the ground up versus the Linux assignments that had to be a lot more focused. (The lessons I learned from having done NACHOS in '94 I still use today.)
The assertion that cheat checkers don't work well with homework assignments is true for small enough units of code, the kind found in introductory courses. Even then, you'd be surprised at how different 30 people can write the same simple program. Cheat checkers used in those classes generate several false positives per assignment that usually get human review. One match between another student is usually tagged as a "whatever", the second gets noticed... three or four in a row of the same two or three students and you have a real problem. Legit submissions that hit false positives usually match different students on the second and third try. By the time assignments get into second year CS programs, assignments are several hundred lines long and usually are sufficiently different to not get matched at all from different implementations. Third year assignments and any matches are immediately suspicious.
In general, professors use cheat checkers as a tool to identify trends. Final decisions are made by the professors themselves -- they're CS grads, they know that cheat checkers aren't perfect. A few hits and you usually get a meeting with a prof with a few questions. If you know the material and can explain the code, you're fine. You'd be amazed at the number of people that get into that situation and can't explain the code one bit.
In the end, the real losers in this are the students that don't cheat. Not having mastered the art of deception and taking others people work and claiming it their own, those who have been honest end up not making as much money or getting as far with their careers. Those that have mastered deception are the ones that become your Pointed Haired Bosses and lie to you. Funny how that works...
My wife and I IM all the time, even when we're 10 feet away. Within the house, IM messages tend to be "check out this link" or "hey, it's dinner time." Real conversations don't happen over IM within the house for the very reason several folks pointed out -- it's silly and it isn't a real conversation.
An amusing side effect is that it becomes possible to improve your writing and typing skills with IM so long as both parties don't tolerate IM shorthand. i.e., no "u" or "ur" crap. A friend of mine recently learned about the wonders of IM when his fiance worked across the country for a few months. His typing skills really improved as did his written english. IM actually forced him to become an effective communicator. Granted, it's rare for that to happen, but it can if everyone chatting doesn't tolerate broken english. =)
Bottom-line -- IM isn't a substitute for conversation and when I have kids they won't be allowed to get away with not talking, but it does have a place and it can be useful.
Balance.
-Steve
This may be hard for some to fathom, but try this: turn it off. No really. I mean it. When I need to work, I minimize email, go "invisible" on IM, and let voicemail pick up the phone. My cell phone has caller ID so I can ID my wife and know to pick up the phone.
All of these technologies have a way of being turned off and queueing messages for you. Use it. When you're ready for a break or it's just that time again, process them in bulk and get them over with. When I was programming, I only processed email 2-3 times a day (morning, right before lunch, and towards the end of the day) and this worked very well. Having a gig in marketing land has changed my job requirements where I'm actually judged by how often I interact with the sales team and customers so I check mail more often -- but, when I need to get a document written up or read and comment on something else, I minimize it all and focus.
One last note about IM -- have strict rules about IM. I don't socialize over IM when I'm working. I tell friends that are on my buddy lists to not expect a response during typical working hours if they just want to chat. I won't respond. If you want to send a social comment, send it via email to my personal mailbox and I'll get to it when I've got time to socialize.
Sorry kids. It's not the date granted the matters, it's the date filed.
Don't worry about real time updates. Really, it's just not that important. If your family wants to hear from you to know that you're alive, get a cheap calling card and give'm a ring.
;-)
For the purpose of keeping a journal (which is a very respectable thing to do on a trip like that), take your laptop and your digital camera and use it for dumping pictures and taking notes. No internet access. No email. No games. Do nothing on your laptop that you can do at home.
I recently took a trip through California. The laptop rules were simple: dump pictures onto it and jot down notes. That's all. And you know what -- I loved it. My wrists felt better, my head was less congested, and I spent enough time checking out things that I normally don't get to see. You know... a vacation...