Игорь, поэтому и писал, что можно не столкнуться, все зависит от специфики, не все пишут демонов на PHP.
По-моему учить все что под руку попадется, ради "было бы не плохо", это просто тратить время и в итоге не уметь ничего полезного. Учить ассемблер? Зачем? Это уже третья ниша, совсем иная. Где планируете применять? Ладно бы Си (про web видно уже речи не идёт), но ассемблер? Когда, уже для микроконтроллеров пишут на java. Причем какой именно ассемблер?
Хотя, если подразумевается, просто узнать что такое прерывания, регистры и уметь разобраться в несложном коде, то это все таки не знание. Сложностей в таком изучении не будет, если, конечно, не с этого начинать, но и пользы для изучения языков высокого уровня немного.
Игорь, а зачем подобная отправная точка нужна, ведь это огромные затраты времени, а писать плохо можно на любом языке. Имхо, начинать изучение 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 это нужно для централизованного управления и более никаких плюсов, это облегчает жизнь специалистов по деплою при работе с десятками разнородных систем, не более того. Используя файлы я могу, к примеру, развернуть несколько инсталляций на одной машине, для переменных придется придумывать костыли. Имхо, вы слишком полярно смотрите на вещи, не бывает идеального универсального решения на все случаи жизни.
Если я не прав, приведите, пожалуйста, аргументацию, чем такой подход выигрышнее. А то вы твердите про неудобство и вредность, а объяснить выгоду не можете.