How to export specific columns in a table to a csv file in mysql

Go to the mysql prompt as usual and run the command:
select id, email from users INTO OUTFILE '/Users/zepho/temp/users.csv' FIELDS TERMINATED BY ',';

This will create a csv file with only id, email columns in the users table in the users.csv file.

ERROR 1 (HY000): Can't create/write to file '/var/empty/projects/gold' (Errcode: 2)
ERROR 1 (HY000): Can't create/write to file '/Users/zepho/temp/users.csv' (Errcode: 13)

If you get these errors run:

chmod 777  /Users/zepho/temp

How to turn off Spring

Spring is a big headache in development environment. Creates weird issues like not being able to play in rails console and is a big waste of time. To turn off spring, in the terminal, run:

export DISABLE_SPRING=1

You will now be able to go to rails console.  You may also have to kill any stray rails

console processes that may be running but never succeeded.

To remove it :

• 'Unspring' your bin/ executables: bin/spring binstub --remove --all
• Remove spring from your Gemfile

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) Mac OS 10.9.5

I was able to connect to the server using SQL Pro but not from the command line. The solution:

$ mysql -h 127.0.0.1 -P 3306 -u root -p

You can also use telnet to check the connectivity:

$telnet 127.0.0.1 3306

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

J

5.6.21 81/8j0O?Am$fZn<||}~!mysql_native_password

!#08S01Got packets out of orderConnection closed by foreign host.

Is TDD Dead Part 3 Transcript Concise Version : Fast Feedback and Quality Assurance

Kent said that decisions involving TDD were about trade-offs: "In some ideal world we would have instant, infallible feedback about our programming decisions", "every key stroke that I make, if the code is ready to deploy, it would just instantly deploy." But that ideal is impossible at the moment so the question is how far do we back off from that. He went to enumerate several constraints in the trade-off.

• Frequency: how rapidly do we want our feedback ?
• Fidelity: how accurate do we want the red/green signal to be?
• Overhead: how much are we prepared to pay?
• Lifespan: how long is this software going to be around, which is a probability as well as time.

Those four are the constraints he thinks we need to compare. "My personal goal is just to understand the set of trade-offs by articulating them to people who are prepared to tear my ideas apart in a constructive way"

Fowler outlined three things that we can look at, to get feedback on:

1. Is the software doing something useful for the user of the software?
2. Have I broken anything? 
3. Is my code-base healthy? This so I can continue to build things quickly.

David introduced the topic that TDD's success had led to a neglect of QA. The other issue is that to understand trade-offs you have to understand the costs, all the talk of TDD has been on the benefits. This neglect of costs is why people cannot comprehend that there is such a thing as test-induced damage. The trade-off continuum is true of other things. Consider the cost of reliability: going from 99% to 99.999% is exponentially more expensive than getting to 99%. We must also consider criticality. High reliability is important for space shuttles and pacemakers, but wrong for an exploratory web site. The rule of not writing a line of production code without a test doesn't fit in with trade-offs around criticality.

David agreed that it was good to mindfully trade-off QA for initial speed, but some have taken programmer testing too far and don't see the value of exploratory testing. Your tests may be green but when it's in production users do things you don't expect.

David says that worst of all is when developers are not part of of customer service. Many programmers don't want to be on-call because it's drudgery, but it's also a feedback loop. Code with green tests can be a plateau that's below where you want to be. "The on-call is the feedback loop that teaches you what tests you didn't write." As soon as you think you don't make mistakes any more, that's a mistake, and you stop growing. He'd rather pay the price of catching that early with a phone call at 2am.

How to use Favicon for your Rails 4.2 app

1. Copy your favicon.ico to app/assets/images folder.
2. In the layouts/application.html.erb add:  <%= favicon_link_tag %> within the head tags.
3. Deploy and enjoy!

Disabling SSL V3 for Poodle for Apache in Ubuntu

1. edit /etc/apache2/mods-available/ssl.conf
2. Look for : SSLProtocol All -SSLv2
3. Replace it with : SSLProtocol All -SSLv2 -SSLv3
4. Test configuration: apachectl configtest
5. Restart Apache : sudo service apache2 restart

Auto Refresh Browser on File Save

I was looking for a tool that reloads static html pages automatically on file save. CodeKit does not work on Mac 10.7.5 and it costs $40. Here is a simple alternative.

1. Install Auto Reload Firefox Plugin
2. Go to Tools -> AutoReload Preferences and turn off notifications. It's a bit distracting.

3. Open the local html file in a text editor.

Now, whenever you save the file, the page will get refreshed automatically. Much faster feedback. I love it.

How to build codeschool.com clone and make $35 million in 4 years!

1. You need Ubuntu 14.04 LTS. I installed it on my $10/month Linode instance. Digital Ocean offers $5/month plan which is good enough.
2. Expose docker to access over network
3. From your machine: $
    ssh root@ip-address-of-your-server
4. $chmod 777 setup-script.sh
   $sh setup-script.sh
5. git clone git@github.com:grounds/grounds.io.git
6. cd grounds.io
7. make pull
8. In ~/.profile add export DOCKER_URL=http://ip-address-of-your-server:4243
9. chmod -R 777 grounds.io
10. Edit fig.yml:
web:
  build: .
  command: rake run
  ports:
    - '80:3000'

11. Run the Rails app:
RAILS_ENV=production SECRET_KEY_BASE="your secret key generated using rake secret" fig up -d

See it in action at www.rubyplus.biz

Is TDD Dead Concise Version : Feedback and QA

Kent said that decisions when doing TDD is about trade-offs, "In some ideal world we would have instant, infallible feedback about our programming decisions"… "every key stroke that I make, if the code is ready to deploy, it would just instantly deploy."  He went to enumerate several constraints in the trade-off.

Frequency: how rapidly do we want our feedback ?
Fidelity: how accurate do we want the red/green signal to be?
Overhead: how much are we prepared to pay?
Lifespan: how long is this software going to be around, which is probability as well as time.

Martin Fowler outlined three things we can look at to get feedback on:

1. Is the software doing something useful for the user of the software? 
2. Have I broken anything?  I want to see every test fail at least once.
3. Is my code-base healthy? So that I can continue to build things quickly. 

The other issue is that to understand trade-offs you have to understand the costs, all the talk of TDD has been on the benefits. This neglect of costs is why people cannot comprehend that there is such a thing as test-induced damage. The trade-off continuum is true of other things. Consider the cost of reliability: going from 99% to 99.999% is exponentially more expensive than getting to 99%. We must also consider criticality. High reliability is important for space shuttles and pacemakers, but wrong for an exploratory web site. The rule of not writing a line of production code without a test doesn't fit in with trade-offs around criticality.

David agreed that it was good to mindfully trade-off QA for initial speed, but some have taken programmer testing too far and don't see the value of exploratory testing. If developers think they can create high-enough quality software without QA they are wrong, your tests may be green but when it's in production users do things you don't expect.

 Programmers on-call is also a feedback loop. Kent said: "The on-call is the feedback loop that teaches you what tests you didn't write."

Reference:

Is TDD Dead? Video
Is TDD Dead? Transcript

TDD is Dead - Part 2 Concise Version

Can TDD lead to design damage? 

This entire debate would not have occurred if DHH had read this quote by Matsuo Basho:

Do not seek to follow in the footsteps of the wise. Seek what they sought.

David's objections:

1. Unnecessary indirection and complexity required to make it easier to test in isolation.
2. Using mocks to isolate from external dependencies

The design David showed wasn't due to TDD, the real issue is that these indirections are all good tricks under some circumstances and we need to understand whether they are worth the cost or not. 

Kent said that developers' make one design decision at a time. TDD puts an evolutionary pressure on a design, people have different preferences for the grain-size of how much is covered by their tests. David replied that there's a direct correlation between the size of code and how easy it is to change it.

David said the reason people wanted isolation was due to TDD. You can't just swap out an in-memory store for a call to a web service because they have different operational characteristics. These swap-ability pipe-dreams aren't the real goal - the real goal is isolated testing. Kent agreed that you can't treat in-memory and web services the same as the failure cases are different. The boundaries between elements will leak to some degree "the question is how much are we willing to spend to get how much decoupling between elements".

Kent saw the difference between 10 lines of code and 60 as a cohesion issue. David agreed but argued that cohesion and coupling are often opposed. Higher coupling is usually worth the price to get better cohesion. Kent observed that there are other ways to eliminate external dependencies, you can also use intermediate results, this is what happens with compilers.

Something that's hard to test is an indication that you need a design insight, it's often useful to get up and take a walk to find those insights that lead to better designs that are also more testable.

 Kent clarified he wasn't talking about TDD, but about software design in general, it's not about TDD it's about how to get feedback. Thinking about software design is the thing, because it pays off so big when you get a good design insight. Getting these insights isn't about your workflow, it's about things like knowing when to work and when to rest, gathering influences from other places, collaborating with other people.

Executive Summary

DHH is not seeking what Kent Beck is after:

1. Fast Feedback Loop
2. Cheap Way to Test Ideas
3. Gaining Confidence  

Reference

Test Induced Design Damage