Monday, December 19, 2011

Focus back

You probably don’t want to admit it but you love distractions. In fact, just like monkeys, you get a shot of dopamine every time something pulls you in another direction. Why do you think you check your email so much?
Want to be more productive and get your focus back? There are no secret tricks here… do one thing at a time. Stop multitasking—it’s just another form of distraction.

Here are his tips for staying productive:
  1. Work backwards from goals to milestones to tasks. Writing “launch company website” at the top of your to-do list is a sure way to make sure you never get it done. Break down the work into smaller and smaller chunks until you have specific tasks that can be accomplished in a few hours or less: Sketch a wireframe, outline an introduction for the homepage video, etc. That’s how you set goals and actually succeed in crossing them off your list.
  2. Stop multi-tasking. No, seriously—stop. Switching from task to task quickly does not work. In fact, changing tasks more than 10 times in a day makes you dumber than being stoned. When you’re stoned, your IQ drops by five points. When you multitask, it drops by an average of 10 points, 15 for men, five for women (yes, men are three times as bad at multitasking than women). 
  3. Be militant about eliminating distractions. Lock your door, put a sign up, turn off your phone, texts, email, and instant messaging. In fact, if you know you may sneak a peek at your email, set it to offline mode, or even turn off your Internet connection. Go to a quiet area and focus on completing one task.
  4. Schedule your email. Pick two or three times during the day when you’re going to use your email. Checking your email constantly throughout the day creates a ton of noise and kills your productivity.
  5. Use the phone. Email isn’t meant for conversations. Don’t reply more than twice to an email. Pick up the phone instead. 
  6. Work on your own agenda. Don’t let something else set your day. Most people go right to their emails and start freaking out. You will end up at inbox-zero, but accomplish nothing. After you wake up, drink water so you rehydrate, eat a good breakfast to replenish your glucose, then set prioritized goals for the rest of your day. 
  7. Work in 60 to 90 minute intervals. Your brain uses up more glucose than any other bodily activity. Typically you will have spent most of it after 60-90 minutes. (That’s why you feel so burned out after super long meetings.) So take a break: Get up, go for a walk, have a snack, do something completely different to recharge. And yes, that means you need an extra hour for breaks, not including lunch, so if you’re required to get eight hours of work done each day, plan to be there for 9.5-10 hours.
for a complete article you can visit the below link

Sunday, December 11, 2011

Monitoring Guidelines

  • Keep it simple stupid.
    • Start with simple monitoring, like PING to make sure that the host is up and standard checks like http, smtp and so on to make sure that standard services are up. Going from no monitoring to basic monitoring is a huge step and many organizations do not have the processes to handle more complex monitoring.
    • The next step is disk, CPU and memory on hosts. On network devices are port load, cpu load, network link.
    • Third step is to dig into bussiness critical applications and services.
  • Small iterations. Do not try to build a top of the line monitoring solution from day one. You will never leave the startup phase.
  • Let the monitoring solution pull the status instead of sending the status to the monitroing solution. This avoid complicated rules when different types of information is sent to the monitoring solution. So avoid sending SNMPtraps.
  • The monitoring solution is NOT a trashcan where to send tons of uninteresting garbage. It is far to common that HW vendors recommends to send thousands of unnecessary SNMPtraps to the monitoring solution and just a few is interesting. It is a nightmare to create the ruleset to figure out what is interesting, especially if there is dependencies where one message is interesting if another message has been sent before. The documentation is a badly written  MIB on a couple of hundered pages. In almost every case I’ve run into with this approch the implementation never ends and test cases are hard to create. When the systems are in production I can bet on that a critical event will occour which has not been taken care of and the production will stop. Managers will be upset, vendors will blame each other and customers will be angry.
  • Let the status be availiable easily:
    • via standard APIs, Perl and Bash is the most common.
    • SNMP via SNMPget instead of SNMPtraps
    • Status stored in a database, the monitoring solution can run SQL quries to get the status.
    • Commands the can be runned by the monitoring solution and the output parsed, or even better, exit codes are used and documented.
  • Normally it is not a good idea to read a log file to understand the status of of the software.