[Ubuntu] Remove Password Prompt For sudo

• Open a terminal
• Run sudo visudo
• Add line 
• <username> ALL=NOPASSWD: ALL
• For example, david ALL=NOPASSWD: ALL
• Save and quit
• Done

From: https://help.ubuntu.com/community/RootSudo#Remove_Password_Prompt_For_sudo

[Blog] Great use of Null Object pattern

Last weekend, I watched a talk Code Smells: Your Refactoring Cheat Codes by John Pignata from MountainWest RubyConf 2013. I was really enjoyed with it. One of the technique that I really like is his use of Null Object pattern. Even though, I know this pattern for long time, but in the situation he was in, I would not be able to come up with the solution like that.

Almost at the end of the talk, his code came to the state that he has jobs and PushDaemon that pushing jobs to the worker. Because a job returned from factory can be nil, he needs to check and allow only non-nil job to be pushed. This is a well-known use case for Null Object Pattern. He modified factory to  return NullJob instead of nil. Now his PushDaemon doesn't need to check for nil anymore.

The code was cleaner without nil checking but pushing null job to worker is not so efficient. How can we avoid pushing NullJob to the worker without checking for nil? That was the time he showed a great technique. Flipping push method (<<) in PushDaemon which was send to worker list to send to job with the opposite direction (>>) and pass worker list as an argument instead. Then implements >> for all the jobs to push itself to worker list except for NullJob. >> of NullJob does nothing. At the end, everything fall cleanly and efficiently.

I highly recommend you to check out his talk for other great refactoring techniques yourself from the link beginning of this blog or on his blog directly.

pg_dump: Error message from server: ERROR: canceling statement due to conflict with recovery

I ran to this error the other day when I tried to export a dump file from a slave Postgres database.

cpg_dump: Dumping the contents of table "[table_name]" failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR:  canceling statement due to conflict with recovery
DETAIL:  User query might have needed to see row versions that must be removed.
pg_dump: The command was: COPY public.[table_name] ([comma-separated column names]) TO stdout;

I turns out that we can't execute long query on Hot Standby mode server. Right now, there's no perfect solution to this problem but there are some couples of workarounds.

• Make a dump from master.
• Set max_standby_archive_delay and max_standby_streaming_delay to be bigger that amount of time it needs to export a dump. This will make slave catching up master version slower. It's not likely to work for a big database.
• Pause sync, make a dump and the resume sync. You can pause sync with function pg_xlog_replay_pause() and resume with function pg_xlog_replay_resume(). See more details on this 2 functions from 9.24. System Administration Functions and New Replication and Recovery Features in PostgreSQL 9.1. Note that we should not pause it too long (> 24 hours), otherwise I might not be able to resume.

Mailing list related to this issue: Hot Standby - ERROR: canceling statement due to conflict with recovery

[RSpec] Refer to let value that has the same name in outer scope

There is a situation in RSpec when you want to redefine let value in the inner scope base on value from the outer scope. In RSpec 2.13, you can do that by referring outer scope value with super() (parens are required)

Credit: RSpec 2.13 is released!

[Watched] Go at Google

http://www.infoq.com/presentations/Go-Google

Interesting points in Go that I learned from this presentation

• You can not have unused import statement. Makes code cleaner and faster compilation time.
• Favor small duplication over including big dependency to use only small part of it
• No implements declaration required for implementing an interface. Safety from static typing and flexibility from ad-hoc type.
• Gofix - Cool tool for changing the code to fix language version incompatibility issue.

[Fixed][VIM] E354: Invalid register name: '*'

This error occurs when you or some of your vim plugins try to access register '*' which is a system clipboard. In default Mac OSX vim, it is compiled without system clipboard support enable. You can check this by run command :version inside vim. In the result, you will see -clipboard. Disable is -, enable is +.

To solve this issue, you need to compile vim with +clipboard yourself. I suggest OSX users to use brew to help this process. Out-of-the-box brew compiles vim with +clipboard. To do this run

brew install vim

Then you might need to create a new symbolic link from your vi command to point to the newly installed vim.
First you need to know the path of your new vim. Run

brew info vim

You should see something similar to /usr/local/Cellar/vim/7.3.875 in the result which means your vim binary file is at /usr/local/Cellar/vim/7.3.875/bin/vim. To create a new symbolic link for vi, first you need to remove the existing link

sudo rm /usr/bin/vi

Then you can create a new link.

sudo ln -s /usr/local/Cellar/vim/7.3.875/bin/vim /usr/bin/vi

PostgreSQL: Listen to remote connection

By default postgres does not allow accessing via ip address, you can only access with localhost. If you try to access with ip address, you will get the error message like this: (assume that 10.0.1.11 = localhost)

$ psql -h 10.0.1.11 dbname
psql: could not connect to server: Connection refused
Is the server running on host "10.0.1.11" and accepting
TCP/IP connections on port 5432?

To allow connection via ip address, you need to add that ip address to listen_addresses config. Here's how to do that:

1. Open file postgresql.conf (the location of the file depend on OS and installed place)
2. Look for listen_addresses
3. Uncomment the line
4. Add ipaddress that you want postgres to listen on inside the same single quote with 'localhost'. Like this listen_addresses = 'localhost,10.0.1.11'
5. Restart postgres server (again depend on your OS on how to restart service)
6. Now, you should be able to access it with "-h ipaddress". Such as psql -h 10.0.1.11 dbname