Игорь, а зачем подобная отправная точка нужна, ведь это огромные затраты времени, а писать плохо можно на любом языке. Имхо, начинать изучение web с C++ очень странное решение. Это совсем другая ниша, и проблемы, которые нужно решать совсем иные. Утечки памяти, сложная работа с типами, в web вообще можно не столкнуться с этими проблемами.
Изучать Delphi это тоже, что изучать Pascal. Разница только в том, что второй уже умер, а первый ещё умирает.
А изучать и использовать фреймворки, как и библиотеки, расширения, это первостепенная задача разработчика, т.к. велосипедостроение крайне не эффективно и потому мало кому интересно.
JZorkiy, нет, не получится, к IDE предъявляются совсем иные требования, скоростной набор и редактирование текста не сильно важны, потребляемые ресурсы не на первом месте, а наличие по-умолчанию в Ubuntu, это не про IDE.
А вот хорошая подсветка нужна, не только синтаксиса, но и ошибок орфографии, не используемых переменных и т.д. Нужны хорошие подсказки, по функциям, методам, переменным и прочему, в том числе по встроеным, нужны удобные переходы по функциям. Нужен удобный дебаггер, в частности вотчер. Это минимум. И, да, в vim многое есть, при расширении плагинами. И, я не буду спорить, если кому-то этого достаточно.
JZorkiy, да ради бога, просто из условия было не очень понятна цель. И я ни в коем случае, никогда, не буду убеждать фаната vim, что есть что-то лучше.
maqstein, вставка строчки с одним индексом также будет проходить быстро.
Можно и Cron, зависит от требований, я имел ввиду, что с Cron не вижу проблем, так что не очень понятно о "более лаконичном решении". Хотя если нужна высокая точность, и отправлений очень много, то нужен постоянно работающий сервис, а не планировщик. Который будет получать данные из базы периодически, а отправлять их строго в указанное время. Быть может, даже стоит посмотреть в сторону сервера очередей.
С другой стороны в postgresql есть возможность слать оповещения при изменениях в таблице. Но это вариант для редких изменений, у вас я так понял иное.
illiatovpeko, а почему вы не проверяете ошибки на стороне БД? Что возвращает mysqli_error?
И, если не получается, подключите xdebug, без него поиск ошибки - мучение.
DevMan, а что вы подразумеваете под тестовым сервером? Для меня сервер на котором будем гонять тесты уже тестовый, не важно отрабатывают они на реальном веб-сервере или эмуляции, не важно отдельная это машина или совмещённая со сборщиком.
И я имел ввиду, что даже большой проект на php собирается гораздо быстрее, чем компилируемый. Поэтому здесь можно собирать сразу, не обращая внимание на время.
Промежуточные комиты не должны, а комиты в ветку dev, вполне можно и даже нужно собрать и прогнать автотесты. Всё-таки это php, процесс не долгий и можно не откладывать в ночь. А чем быстрее отклик, тем эффективнее будет работать CI.
Иван Шумов, хранение не в файле а в переменной - это новомодная технология? И что здесь учить? Ну что ж, раз по делу сказать нечего, и пошел уже переход на личности, значит задел за живое. А я вот, не ценю людей, которые способны только болтать о своей продвинутости, но не способны объяснить конкретику. Ты как сертифицированный тренер, который с упоением рассказывает о вещах, которых никогда не применял.
Иван Шумов,
1) "Таким образом в репозитории не будет доступов, которые могут утечь куда угодно"
их там не будет в любом случае, хранение в файле не значит хранение в репозитории. Равно как и использование переменных окружения не значит, что где-то они не лежат в файле.
2) "Переменными окружения гораздо проще управлять. Если у тебя приложение на компилируемом ЯП то его не надо пересобирать при изменении конфигурации"
проще для кого? Для специалистов по сборке с учетом большого парка разномастных проектов - да. Для одного-двух проектов на php и небольшой команды - без разницы.
3) "Если работаешь с контейнерами то можно иметь любое количество запущенных окружений без каких либо проблем на одной и той же машине"
а если нет? Внедрять контейнеризацию? Ради чего? Где те неоспоримые преимущества, ради которых стоит это сделать?
4) "Для сборки не надо знать структуру приложения: я регулярно вижу что команды начинают писать программу на одном ЯП, а со временем он распадается на микросервисы и язык меняется"
ее нужно знать один раз во время написания скриптов автоматизации, что лучше разработчика работающего над проектом никто не сделает. Даже по 12factor требуется привлекать разработчиков к таким задачам.
"это основные и это очень помогает в разработке. Кроме того конфигурация становится куда прозрачнее - не надо знать в каком файле что такого надо законфигурировать чтобы это все завелось. Вот дали тебе код, а потом что?"
Все перечисленное помогает только осуществляющим сборку, не разработчикам, а если таких выделенных людей нет вовсе, то никому не помогает, а только мешает.
Когда мне дадут код, то без разницы в конфиг-файлах лежат доступы или в них только ссылки на переменные окружения, без нормального мануала по сборке придется разбираться долго, ну как я угадаю нужные переменные окружения?
Даже при использовании больших конфигурационных файлов хороший разработчик позаботится о быстром старте и подготовленных конфигах для разных сред окружения, а будет это в виде переменных окружения или отдельных конфиг-файлов не имеет значения.
Резюмируя, я вижу что все это нужно только для облегчения жизни специалистам по деплою на разнородных проектах. Всем остальным это не нужно, и может даже мешать. А заявления про безопасность не обоснованы.
Я не говорю что переменные окружения это плохо, я говорю, что нет никаких явных преимуществ, есть свои плюсы и минусы, как в любом инструменте. Кроме того, при желании можно те же переменные окружения передавать сборщику, а он создаст конфиг-файлы. Главное чтобы было понимание, почему лично вам так удобнее. Не все что применяется в крупной компании подойдет средней или маленькой, да скорее всего даже другой крупной компании не подойдет. Это как с микросервисами - отличное решение под определенную задачу и ужасное под другую задачу, но сейчас повсеместная эйфория и желание впихнуть их везде.
Иван Шумов, так чем вреден и неудобен подход хранения в файле? Для 12factor это нужно для централизованного управления и более никаких плюсов, это облегчает жизнь специалистов по деплою при работе с десятками разнородных систем, не более того. Используя файлы я могу, к примеру, развернуть несколько инсталляций на одной машине, для переменных придется придумывать костыли. Имхо, вы слишком полярно смотрите на вещи, не бывает идеального универсального решения на все случаи жизни.
Если я не прав, приведите, пожалуйста, аргументацию, чем такой подход выигрышнее. А то вы твердите про неудобство и вредность, а объяснить выгоду не можете.
Спасибо за ссылки, было интересно почитать. Но отмечу, что претензий к хранению в файлах 2:
1) "случайно можно запушить в реп" - случайно можно и не такое сделать, будьте внимательны, в крайнем случае, настройки dev-окружения в репе никого не могут дискредитировать, а вот засвеченные переменные окружения на проде могут.
2) "легче управлять при разнородных системах, языках программирования и т.д." - здесь абсолютно согласен. Но у нас ведь не та ситуация, не всем нужен docker, а многим и CI/CD не нужен.
Поэтому для конфига БД проекта на PHP такие утверждения не истина в последней инстанции. Решения должны быть соизмеримы задаче. Да и в разработке будет не удобно (развернуть несколько инстансов на одной машине, например).
У предыдущего оратора был печальный опыт и он его не может забыть, смакуя проблемы 10 летней давности и считая что Windows магическая система, в которой даже если физически повредить диск данные не исчезнут.
Но нужен ли Linux автору, знает только он сам. И да, программисту нужен, хотя и не каждому.
Я бы начинал с Debian, имхо, гораздо более дружественный дистрибутив. А вот в Manjaro, сколько видел, стабильность хромает, но может дело было в пользователях.