grossws

Как минимум - тильду вместо знака равенства, если локейшн хотите регуляркой задать

Забудь про фриланс, сколько бы про него не говорили, это биржа ДЕШЕВОЙ рабочей силы со всеми вытекающими последствиями в виде кидалова, низкой зп, скучной работы, туда идут люди с серьезными проблемами вроде невозможности перебраться в город, социопатии, инвалидности, "утонченная личность", фриланс это почти всегда вынужденная мера. Вообще фриланс и стабильный заработок несовместимые понятия, просто потому что фриланс подразумевает постоянный поиск мелкой работы, никакой заказчик не будет давать большой серьезный проект фрилансеру никогда, потому что это большая ответственность, посмотрите соседние вопросы, пацики с рейтами 150баксов в час работают 10 часов в месяц, а остальное время ищут заказы, причем это люди с опытом и портфолио + отличный английский. Начинать карьеру с фриланса это 100% гарантия того что, все что можно сделать неправильно (техническая сторона), будет сделано неправильно, потому что работает, дедлайн вчера, а подсказать или сделать код ревью некому, никакие книжки тут не помогут, выбора не будет, ты либо читаешь либо работаешь. Так что не советую ввязываться в эту тему. Лучше начать работы в офисе под строгим надзором. Ну и конечно html+css+js это мало, нужно знать еще около программисткие штуки вроде систем контроля версий, багтрекеры, несколько ide/ текстовых редакторов, если это веб почти гарантированно надо иметь представления о http/https, ООП, возможно sql. Не то чтобы для 20к месяц все это нужно отлично знать, но как минимум иметь представление, чтобы не отвлекаться. Вот по фронтэнду. Для большой гарантии устройства на работу, как уже сказали выше, лучше сделать себе сайт, а еще лучше сделать небольшое портфолио и выложить на гитхаб, это сейчас очень модно. На изучения всего вышеперечисленного уйдет 1-2 месяца если сидеть по 8-4 часа в день примерно, свой сайт где-то неделю на разработку визитки и еще неделя на вылизывание, но оно того стоит, а в процессе поиска работы можно и на гитхаб по чуть-чуть кидать, хотя вряд ли получится много. Удачи.

У вас частный случай известной проблемы, которая называется «не могу оценить требуемые сроки».
Чтобы вы могли планировать сроки и укладываться в них, нужно несколько условий:
— задачу целиком нужно разбить на подзадачи, которые вы уже делали и знаете, какая сколько времени займёт,
— в процессе выполнения итерации требования не должны меняться, в том числе по инициативе заказчика.

Это всё приходит с опытом. Я могу сказать, что ваша ситуация с затягиванием сроков вовсе не является уникальной. Многие разработчики и команды ошибаются с планированием сроков. Это не есть хорошо и правильно, но таковы факты. Не падайте духом. Поймите, что это не ваша вина, и не давайте заказчику «давить на гниль» и подкидывать вам дополнительную работу бесплатно. Он не телефон в магазине покупал, он заказывал разработку, а в разработке всегда есть вилка трудозатрат. Если он этого не понимал — значит он не профессионал. Если при этом он обвиняет в срыве сроков единственно вас и требует: «ты мне обещал Y за X рублей вот и выдай Y кровь из носу» — можете его послать.

Вообще ответ на ваш вопрос «как поступить» зависит от того, как вы договаривались — либо о каком-то объёме работ либо о конечном продукте. Но с учётом того, что у вас на проект уже «не стоит» — не важно как вы договаривались, вариантов немного:
— Объясняете заказчику, что ошиблись при оценке трудозатрат и продолжать на прежних условиях не можете. Сдаёте как есть, деньги не возвращаете.
— Объясняете заказчику, что ошиблись при оценке трудозатрат и в максимально сжатые сроки доводите проект до какого-то логического завершения. Все требования о дополнительных бесплатных работах игнорируете. Сдаёте, забираете остаток денег, забываете.

Первый вариант для вас выгоднее, потому что во втором случае есть риск не получить вторую половину оплаты, а также потому что сдача проекта — это не конец, а начало, т.к. каждому проекту требуется поддержка.

Решение найдено куда более гибкое: использовать cgroups для создания двух групп z0 и z1.

# cd /sys/fs/cgroup/cpuset
# egrep -m1 -He^ cpuset.{cpus,cpu_exclusive,mems,mem_exclusive}
cpuset.cpus:0-7
cpuset.cpu_exclusive:1
cpuset.mems:0
cpuset.mem_exclusive:1

# cd /sys/fs/cgroup/cpuset/z0
# egrep -m1 -He^ cpuset.{cpus,cpu_exclusive,mems,mem_exclusive}
cpuset.cpus:0-3
cpuset.cpu_exclusive:1
cpuset.mems:0
cpuset.mem_exclusive:0

# cd /sys/fs/cgroup/cpuset/z1
# egrep -m1 -He^ cpuset.{cpus,cpu_exclusive,mems,mem_exclusive}
cpuset.cpus:4-7
cpuset.cpu_exclusive:1
cpuset.mems:0
cpuset.mem_exclusive:0

эйфория от новых возможностей прошла и вскрылись недостатки, на мой взгляд основные их них:
— Слабая производительность на 1-серверной БД. Особенно заметно на map-reduce по данным, которые полностью влезли в память.
— Особенности документо-ориентированной структуры. Многие переходили с табличных БД и тут понеслась: сначала радость, что не надо возиться со структурой, а потом расплата — в одной коллекции куча разных объектов и приложение регулярно читает из вроде бы известной коллекции что-то для себя неожиданное (очень старые объекты, некорректно измененные и т.п.).
— Целостность данных. Кто-то привык, что БД контролирует этот вопрос, вешают констрейнты и ловят ошибки в логе в случае какой промашки по части бизнес-логики. Монга же ничего такого сама не контролирует, ну и получаются внутри БД ссылки на объекты, которых нет.
— Отсутствие полноценных транзакций. Те, кто бросились все хранить в монге с ужасом поняли, что для биллинга нужно что-то другое. (должен оговориться, что не все пока поняли)

По моему мнению отказаться от классической реляционной БД в пользу монги может позволить далеко не каждый проект. Если перетаскивать какой-нибудь небольшой интернет-магазин, то с бОльшей вероятностью это принесет боль и страдание нежели ожидаемый профит. Эффективным решением будет параллельное использование монги и реляционной БД, но чтобы это имело смысл — проект должен быть соответствующих размеров. Для небольшого проекта городить такой огород контрпродуктивно.

PS Мое мнение основано на годичном опыте неплотной работы с монгой, опыт работы с реляционными БД — примерно 10 лет.

Это курсовая разница, все нормально. Снимает не aliexpress, а сами ЯД. Иногда не снимают, а наоборот, начисляют.

См.: money.yandex.ru/doc.xml?id=524783#shops, вопрос «Через несколько дней после того, как я заплатил с карты, с моего счета дополнительно сняли небольшую сумму. Почему?».

RewriteRule ^ru/(.+) /$1 [R=301,L]

примерно так

У получателя есть аккаунт на Google(+) с привязанным ящиком от hotmail.com

Тип резьбы:
en.wikipedia.org/wiki/ISO_metric_screw_thread#Designation

External threads are designated by lowercase letter, g or h. Internal threads are designated by upper case letters, H or G.

www.ergotron-russia.ru/products/direct/default.html