5 Reasons to Wake Up Earlier (and 2 Reasons to Skip It)

Jen Hubley Luckwaldt

Could you wake up two hours earlier every day? Rachel Gillett at Fast Company tried it for a week, rising at 6:30 a.m. and tallying up the ways in which it improved her productivity and happiness, both in her personal life and at work -- plus, a few of the challenges involved in resetting her daily clock.

First things first: waking up earlier won't work for everyone.

1. Experiments like these are easier if you're not a working parent.

"Many [parents] pointed out that they rarely have the luxury of sleeping until 6:30 a.m., which would make their wake-up time for this project much earlier," writes Gillett. "This seems implausible, though some have done it."

Her colleague Scott Thigpen, for example, regularly rises at 3:50 a.m., in order to have some peace and quiet before his two children wake up. He often meditates during his morning hours, which sometimes just consists of quietly enjoying a cup of coffee without interruption.

2. Not everyone's work and life rhythms are the same. 

If you're a morning person, waking up earlier buys you extra hours to create and think, but if you're a night person, you might just feel exhausted, as if you're tacking on more unproductive time long before your brain kicks in.

If you can get stuff done in the morning, however, there are rewards to getting up much earlier than usual, including:

1. Increased energy, especially if you, like Gillett, use the time to work out first thing in the morning.

2. Weight loss. Again, the early morning workouts might help, but so can having a bit more time to plan meals, eat slowly, and just generally reduce stress.

3. Improved punctuality. One reader tells Gillett that getting up earlier makes it easier for her to make early-morning meetings and flights.

4. More time to yourself. Want to train for a marathon, write a book, or pick up a hobby you abandoned years ago? Getting up earlier than everyone else is a great way to do it.

5. Less rushing around. Some stress is healthy, inspiring us to do our best work, strive for a goal, or improve ourselves. The pressure we feel when we're constantly just a few minutes behind isn't that healthy kind of stress. Get up earlier, and you start the day ahead, instead of behind.

 

Execute Sql Commands through Command Prompt

Here I am sharing that how can we execute SQL Commands through Command Prompt.

Using this command line utility, we can also fire queries and execute files, etc.

Sample Syntax:

SqlCmd -S servername -U "username" -P "password" -q "sql command"

 

Ex.

SqlCmd -E -S 192.168.0.1\Sql2008 -Q "BACKUP DATABASE Practice TO Disk='C:\dbbackups\db_Practice.bak';BACKUP LOG Practice TO Disk='C:\dbbackups\db_Practice.bak';"

 

SqlCmd -S 192.168.0.1\Sql2008 -U "sa" -P "sa@123" -q "RESTORE DATABASE Practice FROM DISK = 'e:\Backups\db_Practice.bak' WITH MOVE 'Practice' TO 'G:\DBBackups\Practice.mdf',MOVE 'Practice_log' TO 'G:\DBBackups\Practice.ldf';"

 

For more options check below detail:

 

sqlcmd 

   -a packet_size 

   -A (dedicated administrator connection)

   -b (terminate batch job if there is an error)

   -c batch_terminator 

   -C (trust the server certificate)

   -d db_name 

   -e (echo input)

   -E (use trusted connection)

   -f codepage | i:codepage[,o:codepage] | o:codepage[,i:codepage]

   -h rows_per_header 

   -H workstation_name 

   -i input_file 

   -I (enable quoted identifiers)

   -k[1 | 2] (remove or replace control characters)

   -K application_intent 

   -l login_timeout 

   -L[c] (list servers, optional clean output)

   -m error_level 

   -M multisubnet_failover 

   -N (encrypt connection)

   -o output_file 

   -p[1] (print statistics, optional colon format)

   -P password 

   -q "cmdline query" 

   -Q "cmdline query" (and exit)

   -r[0 | 1] (msgs to stderr)

   -R (use client regional settings)

   -s col_separator 

   -S [protocol:]server[\instance_name][,port]

   -t query_timeout 

   -u (unicode output file)

   -U login_id 

   -v var = "value" 

   -V error_severity_level 

   -w column_width 

   -W (remove trailing spaces)

   -x (disable variable substitution)

   -X[1] (disable commands, startup script, environment variables and optional exit)

   -y variable_length_type_display_width 

   -Y fixed_length_type_display_width 

   -z new_password  

   -Z new_password (and exit)

 

   -? (usage)

 

 

For Detail about "SqlCmd" Visit: http://msdn.microsoft.com/en-us/library/ms162773.aspx

The four golden rules to be a better software developer.

Written by Alberto Gutierrez

• The research to become a better software developer is core to any good software developer. Being a better software developer reflects directly in the code you produce, the better software developer you are, the less bugs, easier to read and easier to maintain code you will produce.

  What follow are the four rules I use on my day to day work to help me become a better software developer.

  Rule number 1:  My code is crap.

  All code is crap, and that includes yours, (and mine, of course). No matter how brilliant a piece of code you think it is, there will be always better ways to implement it, and several programmers who will hate it.

  Even if you are sure your code happens to be good, force yourself into "my code is crap" mode, and ask around about improvements, be open minded and you will see soon how you will find issues in your code that you never have thought about.

  Rule number 2: Even if it's crap, I care about my code.

  It is not about creating the best code upfront, is about making it better every time you visit it. When you finish some functionality, you are not done, I haven't met any programmer that produces acceptable code on their first attempt, you need to polish it. Refactoring is then one of the main activities you should be performing.

  Rule number 3: My opinion about my own code is wrong.

  We are so egocentric that we end up believing that what we have produced, no matter how bad it is, is the best solution as possible. Never trust your own opinion, show your code to as much developers as possible and listen to them.

  Rule number 4: My manager doesn't care about my code, and he pays me.

  This rule regulates the other three, it is easy to forget that you actually get paid to get things done, your manager should also care about the code, but he is more focused in completing things on time with an acceptable quality, so be careful not to expend too much time just making sure your code is not that crap. The key is being able to balance getting things done and their quality.

  Bonus: A few tips to help you with these rules.

  Code reviews.
  Keep it simple.
  Test.
  Refactor.
  Non technical factors.