Тогда стоит поискать людей с отзывами и рейтингом на тех же биржах. Всего скорее удастся договорится о part-time работе. Но, как и писал выше, нужно быть готовому к менеджерской работе. Т.е. искать специалистов; составлять задания; оценивать их по цене, срокам, обговаривать эту оценку с соискателями; контролировать сроки и в случае провалов, тут же передавать задание другому.. Это то ещё удовольствие..
Рано или поздно, у Вас появится список 3-5 более менее надежных фрилансеров, в 90% случаев это покроет Ваши потребности.
Другой способ, это попробовать найти несколько ответственных студентов 3-5 курса из своего города и взять их на неполный, но фиксированный рабочий день (например с 17 до 22 должны быть онлайн). Разумеется, у них должен быть уже какой-то опыт разработки. Так же найти более опытного программера, для ревью кода (либо договориться с существующим парнем). Тут тоже много менеджерской работы. Студентов найти будет не сложно, расклеив объявления на существующих факультетах и пообщавшись с людьми в деканате. В этом варианте плюсом будет то, что можно раз в неделю встретиться и обсудить все проблемы тет-а-тет.
разумеется, это всё "не серьезно", а развлечения ради. От function и других зарезервированных слов избавиться без транслятора или перекомпиляции самого движка не удастся, во всяком случае я не знаю как это сделать :)
Антон Locksly: Значит этот пункт можно снять, я не тестировал на моб. девайсах. Просто сузил окно броузера до ~ 300px по ширине и появился горизонтальный скролл, из чего сделал свой вывод.
Пума Тайланд: у меня несколько раз в год сыпется файл индексов самой большой таблицы. Чаще всего это связано с такой ситуацией: вылетает один из винтов в рейде (или готовится к смерти), пул запросов к бд переполняется, т.к. база не может работать. После этого все запросы убиваются через kill, и mysql завершается с помощью service mysql stop. После замены hdd и синхронизации винтов, у таблиц появляется статус "используется" ("in use"), помогает только: myisamchk с увеличенными буферами, но на таблице в 850 Гб, никакие буфера не помогут, все очень медленно..
Т.е., да, проблема изначально не в MySQL, а в том, что при стечении обстоятельств файлы портятся, и в моем случае, к сожалению, это происходит довольно часто.
Даже если рассмотреть проблему, с упавшим сервером. Предположим что посыпались файлы используемых при падении таблиц, то правильно ли я понимаю, что при использовании партицированния, вся таблица перестанет работать, в независимости от кол-ва испорченых файлов? В случае использования отдельных таблиц, мне кажется, вероятность вылета уменьшится и при этом их можно будет быстрее вводить в строй.
М.б., Вам на вскидку приходят в голову, какие-то другие проблемы разделения данных?
Дальше ресайзишь десктопный броузер, и смотришь как оно будет выглядеть. В Chrome размер окна видно в Dev Tools (F12), в FF я смотрю в Firebug-е, на вкладке HTML>Макет
Не знал о такой возможности, буду тестировать и рассматривать.
Возможно, у Вас уже есть опыт использования партицирования и сможете подсказать, что будет, если один из файлов партиционированной таблицы посыпется? Как я понимаю, все запросы к данной таблице до восстановления посыпавшегося файла перестанут работать, до полного восстановления таблицы ( тут, написано что " [при] SELECT, INSERT, UPDATE MySQL произведет следующие манипуляции: откроет все партиции всех таблиц участвующих в запросе..". Это значит что при выходе из строя 1го файла таблицы, например файл буквы "A", таблица не может быть открыта, хотя запрос будет использовать только файл на букву "Z"). Так ли это?
Если так, то это не даст преимуществ, перед распределением данных по разным таблицам, где за каждую будет отвечать отдельный независимый файл, и в случае проблем, я быстро смогу идентифицировать проблему. Так же возникает вопрос, как найти именно плохой файл среди файлов "партиций", чтобы сразу начать восстанавливать именно его?
curl_close, можно добавитьif ($err=curl_error($curlInit)) var_dump($err);документация по curl_error тут