Categories
Programming

MySQL Dumping Cheat-Sheet

Make a quick dump of a mysql database:

mysql_dump db_name > backup-file.sql

You can then read that dump file back into the server like this

mysql db_name < backup-file.sql

or like this:

mysql -e “source /path/to/backup/backup-file.sql” db_name
Categories
Programming

List of Ruby Operands

operand what it does
<< append (in context of strings, arrays, IO); shift position of bits in Bignum and Fixnum
>> shift position of bits in Bignum and Fixnum
~ bitwise NOT (high-presendence)
& bitwise AND (medium-presendence)
| bitwise OR (medium-presendence)
^ bitwise XOR (medium-presendence)
** exponent
+ addition
subtraction
* multiplication
/ division
% modulo operator
Categories
Programming

Tips for Working with Rails

  1. Go to script/console to open ruby in interactive mode. script/console loads your environments (everything in environment.rb and all your plugin and gem initializers), so you basically have access to all your models right from interactive ruby mode (IRB).
  2. Remember use of the p (or its alias puts) command to print stuff to the output buffer. This is useful for testing in IRB mode, inside of a test, or other places where you have an output buffer. If you’re running mogrel, your output goes to the terminal. If you’re running Passenger with Apache, check your apache error_log for the output.
  3. Puts is not to be confused with logger.debug which will log the output of whatever you pass it to your log/development.log file. To see the log file as your are running, use this:
    tail -f log/development.log

    (The -f flag keeps the tail process running and will show you anything that is written to your log file as it is written.)

    You can see lots of info in the development log of course: all the actions that Rails is trying to render as well as all the SQL it is executing. Like I said above, use logger.debug to explicitly send stuff you want to see to this log.

    This only works in controllers:

    logger.debug “the value of myVar is #{myVar}”

    But this works everywhere:

    RAILS_DEFAULT_LOGGER.info
  4. Don’t forget your <em>explicit conversions</em>. These will work on most objects (where it makes sense) and will convert the variable to something that can be read easily:
    to_s  to string
    to_i  to integer
    to_f  to float
    to_a  to array
  5. Use the string concatenator (plus sign), like so:
    puts “myVariable is ” + myVariable.to_s
    logger.debug “the value of myVar is” + myVar
  6. Use inspect or dump to look the contents of a variable command as in
    myVar.inspect
    myVar.dump

    (You might want to try this):

    p myVar.inspect
  7. The inspect command often will output a long object (as in, lots of output). If you see \n markers (newline) in your output and it all runs together on one line, try “y” before the object to make it more readable. This also shows it in tree-like mode which helps you to see the objects within arrays and stuff. This works well in IRB:

    y myVar

  8. Keep in mind that you can do this stuff inside your tests too. (puts output will be printed by the test runner.) For functional testing, remember the “four Hashes of the apocalypse” – hashes which contain interesting information after your tests have run. Interesting enough to perform asserts against:

      * assigns Any objects that are stored as instance variables in actions for use in views.
      * cookies Any cookies that are set.
      * flash Any objects living in the flash.
      * session Any object living in session variables.

    Also, you can look at the response you’re getting with @response. Also keep in mind:

      * @controller The controller processing the request
      * @request The request
      * @response The response

    I like to use inspect on these, and surround them with big markers so that I can see them clearly when I’m running my test.

    puts “===== RESPONSE====== ”
    puts @response.inspect
    puts “==================== ”