Николай Турнавиотов

Вам в любом случае поддерживать логику этого ключа за пределами базы.
Можно сделать не пересекающиеся инкримент( один от 1 до 100, второй со 101 до 200, типа того ) можно внешнюю таблицу, можно отказаться от числового ключа и использовать uuid.

С html я на вы...

В вашем случае изучать языки скорее всего не самый легкий путь.

Если цель научится и сделать все ручками, то простенький скрипт на PHP будет работать просто из документации https://www.php.net/manual/ru/pdo.construct.php
Но что бы заработал PHP, нужно его поставить, поставить веб сервер и т.д. и т.п. В целом уже есть готовые хостинги со всем этим добром. Тогда остается просто создать index.php, вставить код из документации и вызвать site.com/index.php

Если цель поднять просто поднять какой-то сайт, то вам к wordpress и прочим платформам

почему бы не изучить языки программирования прежде чем создавать приложения?

я сам не программист - помогите мне написать программу, а то у меня лапки...

Нужен ишак, идущий с семеркой и соответствующая ему жаба. Нужен именно ишак, ни в чем другом не заработает. Мы так ходим на G5 какой-то старинный одноюнитовый.

Внутри виртуалки можно показать сколько угодно ядер - это не гарантирует, что вам дадут нагрузить физический процессор/ы полностью. Если сервер не ваш - проще всего уточнить у хостера. Если ваш - вопрос становится тривиальным.

обычно есть 2 пути:

1. Оценка по фикс-прайсу
   
2. Или Time&material.
   

Первый путь начинается с анализа ТЗ, конечно же. Иногда, у заказчика есть какое-то описание в виде текстового файлика, мокапа, дизайна или ещё чего-нибудь. Если же нет, то тебе придется как-то формализовать его хотелки, перевести в понятный вид и написать тз самому, не для него, а для себя прежде всего. В нем ты описываешь весь функционал, который требуется, поведение пользователей, примерные нагрузки и т.д.
Чем детальней написано тз - тем лучше.
Например:
Плохое ТЗ: В приложении можно авторизоваться через email/соцсети.
Хорошее ТЗ: В приложении можно авторизоваться через email и соцсети facebook, vk, instagram. Пользователь может проходить авторизацию через любую соцсеть, при этом при авторизации через ещё непривязанную соцсеть мы должны обновлять данные пользователя.

Дальше ты разбиваешь ТЗ на отдельные части, которые ты можешь оценить.
Например:
Авторизация по email: 2-3ч + 3-5 на каждую соцсеть.
На те вещи, которую ты знаешь и много раз делал закладываешь разброс поменьше, то что не делал - побольше. НА интеграции с третьесторонними сервисами типа соц.сетей, платежных систем, закрытых API, невнятно описанных вещей в ТЗ и т.д. делаешь большой рейндж, т.к. велик риск проблем с доступами, сложностей получения, неактульных документаций и прочим. Если что-то непонятно, лучше спросить у заказчика заранее и описать возможные проблемы, возможно, вы найдете другое решение.

В конце концов у тебя получится 2 оценки - оптимистичная и пессимистичная. Можно ещё добавить какой-нибудь коэффициент, на который надо умножить, если твои оценки обычно слишком оптимистичны ("да тут работы на 2 дня", а сидишь неделю) или наоборот, излишне пессимистичны ("мне надо месяц, а делаю за неделю").

Далее ты понимаешь работа займет, к примеру 250-300 чч, умножай её на свою часовую ставку. вот ты и получил примерную стоимость работ. Не забудь прибавить стоимость всех материальных затрат, специфичных для (хостинги, доменное имя, спец. оборудование, доступ к платному АПИ).

Также не забудь учесть, сколько ты сможешь работать, а то он может подумать, что это 250чч - это 1 месяц работы, а в реальности у тебя основная работа/семья/кошка и ты можешь дать только 100чч/месяц.

2 путь сложнее:
Заказчик любит менять концепцию, тз нет и не будет ему важно быстро тестировать свои идеи и что в итоге выйдет он плохо себе представляет - тогда ты просто ему озвучиваешь стоимость часа и сколько времени ты можешь ему уделить. Основные сложности - это то, что можно нагородить говнокода из-за постоянных изменений, и каждая дальнейшая правка будет занимать все больше времени, а рефакторинг в таком случае очень трудно продавить.

ну всё е просто -

оцениваешь свой час работы, или месячную плату при полной занятости

и приблизительно оцениваешь время на разработку и тестирование
с запасом раза в полтора-два

разработка и дизайн - процесс непредсказуемый и дорогой
поэтому у нормальных дизайнеров девиз такой:

дорого долго прекрасно

ты либо с запасом определяешь сроки, либо в спешке и стрессе работаешь
стресс и спешка несовместимы с качественным дизайном
для хорошего дизайна важно работать в хорошем настроении

1. Только для Windows Server. Для десктопных систем по лицензии одновременно с рабочим столом может работать только один пользователь.
2. Если программы установлены "для всех", в Program Files, то они доступны всем пользователям. Если "для меня", в User\Application Data, то только тому пользователю, кто их установил.

Для рассылки думаю удачнее будет платный сервис рассылки и работа с ним по API.
Запустить почтовый сервер - дело не хитрое.
А вот поддерживать его - задача сложная, и дорогая.

Игра отстой, но во всяком случае в текущем моем понимание.

Но сделать ее можно очень просто, с одним запросом.

1) заходим на страницу, размещаем пушку и сохраняем ее на сервере.
2) запускаем таймер, если это первая пушка.
3) заходим на страницу, размещаем пушку и сохраняем ее на сервере. ПОВТОРИТЬ сколько нужно раз
4) Таймера 2 один на сервере, другой у каждого клиента, можно сихронизировать через Websocket. Однако, это не нужно.
5) Потом на сервере происходят расчеты и сохраняется в текстовом виде, потом раздается всем пользователям.
6) Они по своему клиентскому таймеру сделают запрос.

Нет понятия перейти, есть понятие программировать на каком либо инструменте. Переходят дорогу.

>Можно ли перейти на rails
Приходите, разрешаем.

>не стану ли я говнокодером
Гавнокодер - человек, который пишет плохочитаемый и плохоподдерживаемый код. Если вы планируете писать такой код, то пожалуй станете. А если не планируете, то не станете.

>или лучше всё таки углубиться в php
Язык не имеет значения. Можете ПХП варите его. Вакансий море, зарплаты сравнимы. Если вам легко дается руби, а пхп идет тяжко, смысл попробовать сменить есть.
Я бы не менял, а смотрел в сторону (laravel, symfony, phalcon)

Теоретически - можно, я так и сделал (на месяц). Но ты будешь говнокодить и рано или поздно начнешь изучать Ruby. Нельзя писать не фреймворке, не зная основ. Вы же не пишете на JS-фреймворке, не зная основ JS?
Каждую команду и метод будешь гуглить - а это не круто...
Хорошие курсы по руби есть на codeschool, codeacademy.