Getting the following error when installing mysql2 gem in Ubuntu 14.04?
“Error installing mysql2: ERROR: Failed to build gem native extension.”
This is because you are missing the libmysql-ruby package. To fix, just run the following to install it.
sudo apt-get install libmysqlclient-dev
These are the procedures I followed for Ubuntu 14.04 LTS but should work with other Debian distros.
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
sudo swapon -s
Once you’ve done this you could make this permanent by editing the /etc/fstab file:
/swapfile none swap sw 0 0
If you’re using CentOS 7, Patrick in comments points out:
- The fallocate failed if you did not use ‘sudo’.
- the ‘swapon’ command failed on the root xfs, moved swap to ext works fine.
Let me guess, you’re trying to setup MySQL replication and you end up with errors like the following:
- ERROR 2026 (HY000): SSL connection error: protocol version mismatch
- ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation
- Mismatch is usually because you’re trying to authentication with your client certificates. Using the –ssl-ca flag is sufficient.
mysql -utransmed_app -p --ssl-ca=/etc/mysql-ssl/chain-cert.cer -h dest.example.com
You MUST use a chain cert.
- ERROR 2003 (HY000): Can’t connect to MySQL server on ‘example.com’ (111)
This example was done with Percona Server 5.6 on Ubuntu 14.04 LTS with Comodo Certificates.
Some MySQL selections don’t support the PKCS#8 format.
-----BEGIN PRIVATE KEY-----
This occurs when keys are generated with OpenSSL 1.0+. To fix this issue you simply convert the key to PKCS#1 format:
openssl rsa -in pkcs8-key.pem -out pkcs1-key.pem
You should now see:
-----BEGIN RSA PRIVATE KEY-----
Keep in mind you can’t just simply insert “RSA” into the PKCS#8 format. It won’t work! They’re different formats altogether. You can verify the certs/keys:
openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
Additional troubleshooting tips:
- Make sure both servers have SSL enabled. Make sure the master_ssl_ca has the entire CA chain or it won’t work!
ssl-ca = /etc/mysql-ssl/chain-cert.pem
ssl-cert = /etc/mysql-ssl/STAR_example_net.pem
ssl-key = /etc/mysql-ssl/wildcard-cert.pem
mysql> show variables like "%ssl%";
| Variable_name | Value |
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | /etc/mysql-ssl/COMODO-chained.pem |
| ssl_capath | |
| ssl_cert | /etc/mysql-ssl/STAR_example_net.pem |
| ssl_cipher | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_key | /etc/mysql-ssl/wildcard-cert.pem |
- If you run into this error: “Slave failed to initialize relay log info structure from the repository” you just need to run “RESET SLAVE;”
- Make sure your firewalls have Port 3306 (or whatever port you’re using) open.
- Make sure secure_auth is on:
show variables like "secure_auth";
| Variable_name | Value |
| secure_auth | ON |
- Make sure you’re granting the correct permissions:
GRANT REPLICATION SLAVE ON *.* TO firstname.lastname@example.org IDENTIFIED BY 'SecretPassw0rd' REQIURE SSL;
- You should have master_ssl set to 1:
change master to
When you’re a start-up, you don’t have the luxury of learning by failing. Communication has to be tight and often, you want to follow best-practice principles, and you want passionate and skilled individuals to work for you. You want a Minimum Viable Product that will allow you to go to market quickly. One way to get great results (within budget) is to offshore work on freelance sites like ODesk.
Common complaints about hires:
- “He disappeared the the middle of a project!”
- “He just broke everything and left”
- “He had such great references but ended up being worse than other developers at half the cost.”
- “My internet connection went down and I won’t have internet connection for another 10 days”
- “I’m out of time right now and there’s no signal”
- “My mom is in the hospital so I will not be able to work on your project for a week”
- “The quality has deteriorated over time and I’m pretty sure they’re using a cheaper contractors at the same price.”
- “I need to attend an important conference 20 hours from my current location.”
- “What is this extra charge on this invoice?”
This a quick list of tips and tricks. Keep in mind it is difficult to evaluate skills which you don’t possess yourself:
- Have a detailed list of requirements (e.g., certifications, language, location, etc). It helps to look at previously completely, similar projects.
- Smaller projects are easier to deal with. Break up your project into smaller jobs and have deliverables and deadlines in writing. If they exceed the deadline without notice, cancel the job.
- If you have a long term project, most contractors would be open to drop their rate.
- Give different teams different, focused pieces of a large project.
- If they inflate your billing, fire them.
- They will cost you more in the long run.
- Integrity is of utmost importance when selecting a freelancer, but is generally hard to determine in the short-term.
- Don’t disappoint yourself. You have to do your due diligence.
- References don’t matter much but do review all feedback.
- Make sure they have the mandatory skills.
- Most of the contractors, from my experience, exaggerate their skill sets.
- Look at previous non-NDA’ed work and portfolios.
- Have them describe their thought process and approach to completing the task.
- Take a look at some of their work on Github. This will provide enormous insight into the skill, personality, and ability of the applicant to follow instructions.
- Give them a pre-paid “test period” by creating a private job listing for the list of your final candidates.
- What project management tools do they use?
- Most applicants won’t live up to the hype. It’s really difficult to find those who are passionate. Most budget developers (at least from my experience) are driven by money. Above average cost contractors tend to be more dependable and more aligned with their resume.
- Your requirements need to be as specific as possible.
- This will lower your costs in the long run and is worth the effort to come up with detailed specifications.
- Start high level and go into the details.
- Functional and technical specifications need to have of the highest quality. You should include wireframes, mock-ups of the UI, database schema examples, work/process flow charts, use cases, specific details per section, any CRUD related operations per page, etc.
- Make sure they’re comfortable with TDD, BDD, etc.
- Make sure they understand the framework ecosystem very well.
- Payments should revolve around your use of milestones.
- Make sure your contractor knows the workload size and requirements and the associated payments.
- If English is your primary language, ignore prospects where their English is suspect.
- Make sure you get support after the job is completed (in writing). Defects/bugs could appear at a later time depending on how current/new users interact with your application. 1.5 to 2 months should be sufficient.
- Plenty of agencies and contractors “fish” for contracts using automated or manual processes. To eliminate this, have them place a secret code word in the subject and at the beginning of their application. This way you could visually filter out these type of contractors.
- Keep cultural and geographic differences in mind.
- In India, there are an ungodly number of holidays. Weddings lasts weeks and some tend to work on a more balanced schedule. Make your expectations and timelines clear and in writing.
- What are their regular working hours?
- How proficient are they at communicating in English?
- Hiring from agencies allow you the flexibility to have a “fail-over” contractors.
- Be wary of agencies that try to pull a contractor off in middle of a project and try to coerce you into hiring a second developer, just in time to bill you for two developers when the previous one “returns.”
- If another developer is required, make sure you find out how much time he/she will take to ramp up to the current assignment.
- The major drawback of having an agencies is the lack of one-on-one interaction.
- If possible, interview them over webcam. That way you have one more way to verify the developer you hired is same one you interviewed.
- Code review. This is a great indicator of skill and to make sure the quality is aligned with the agreed rate.
- Have a strong feedback loop in place. The quicker you get to “instant feedback” the better. From my experience, the slower you are to responding to questions/suggestions, the more your investment leaks out (time, money, goals, etc).
- Generally if you have good communication structure in place (Hangouts, Skype, screen-sharing, etc) and a genuinely skilled contractor, you’ll get great results.
- Meet everyday with stand-ups via webcam.
- Have them send you a daily report of the work they’ve done.
- If they’re not performing up to standard, fire them quick and find someone else. More often than not, they’re just a dead-end. The under-performers are obvious within a month while the stronger contenders will be able to handle increasingly difficult tasks.
Keep in mind certain programming languages have a larger presence than others depending on region. Since we’re a Rails shop this article has a systematic approach on what to look out for.
Getting the following error when trying to change your mac terminal to use zsh?
chsh: /usr/local/bin/zsh: non-standard shell
All you need to do to fix this is to add the zshell path ( /usr/local/bin/zsh) to your /etc/shells file.
sudo vim /etc/shells
I added /usr/local/bin/zsh to the end of the file.