Ivanq

Ряды можно сделать в виде div элементов, дать им свойство text-align: center, внутри них добавить еще div-элементы (места) со свойством display: inline-block, указать им фиксированную ширину и высоту. Места эти сделать двух типов: невидимые и реальные. И затем заполнить ряды этими "местами". Название рядов можно сделать с помошью псевдоэлементов ::before и ::after, но это необязательно.

ничего не понял

Предположим, я что-то поделал на компе, недоделал, закоммитил в локальный репозиторий и запушил на сервер

зачем вам коммитить в локальный репозиторий?

Но при таком сценарии использования на сервере будет куча коммитов с недоделланым функционалом. Фактически удаленный репозиторий станет лишь местом синхронизации файлов.

Ору!! А тебе что нужно? Что бы каждый коммит был законченным изменением? Разбивай тогда задачу на мелкие подзадачи.

Лично я когда делаю что-то в одиночку, свой проект - у меня гит именно как средство синхронизации файлов. Хватает с головой. За несколько лет пиления своего кода ни разу мне не потребовалось ничего из гита, вообще, хотя не раз проект переписывал, менял архитектуру и т.д. Мне гитхаб нужен исключительно как средство не профукать код и на работе склонировать поковыряться в своем говнокоде, когда задач нет.

Написал метод, верстку сделал или рефакторинг - пушу. Даже комменты не пишу.

Все просто, работаете на компьютере. Перед тем как закончить, все коммитите и делаете push. Сели за ноут делаете pull.
Если пилите новую фичу, или что то глобальное, лучше создать отдельную ветку, и пока все не закончите делать на ней. На само деле это не обязательно, так как в любом случае все commits и history будут и так видны, а накосячить одному, мало реально, даже если делать все на мастере.
Главное, не забывать простое правило, сел за комп pull перед уходом от компа push.

Если вы не фиксите баги в старой версии, одновременно делая и новую версию - то отдельные ветки вам не нужны.
Для начала освоение научитесь делать четкие коммиты. Чтобы изменения (файлы включенные в коммит) и цель этих изменений (комментарий коммита) совпадали

Есть очень простое правило - правильно так, как проще.

Можете вовсе использовать master для синхронизации всех файлов, ничего страшного если идет активная стадия разработки, Вы единственный разработчик, а релиз еще очень нескоро. И если умеете не перескакивать от одной недоделанной задачи к другой.

Как только понадобится делать релизы, там уже можно заморочиться с master, staging, feature-бранчами и тп, но только по мере необходимости.

PS. Раз уж мы действуем по принципу KISS, вместо утилиты командной строки лучше использовать удобный GUI, например на Mac это Source Tree (по-моему самая классная программа на моем ноуте).
Это также поможет работать с гитом правильнее - вручную просматривать и стейджить каждый измененный файл, а не через git add -A.

Работаете в ветке dev, периодически вливая ее в master. Для крупных задач (не входящих в один коммит) делаете отдельные ветви из dev.

Вливая dev в master, делаете это с ключом --squash как то так:

git checkout master
git merge --squash dev

Тут теоретически могут быть конфликты, если вы делали коммиты в masterпараллельно с dev, которые вам надо разрешить, а после уже добавляете и делаете один большой коммит:

git add -A
git commit -m "Merged dev: %кратко (или нет) основные изменения%"
git push

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

git checkout dev
git rebase -i master

Откроется редактор, в котором будет список коммитов ветки dev. Здесь можете слепить ненавистные коммиты с помощью команды squash (и тогда вам предложат отредактировать сообщение) или fixup (тут не предложат) и потом сделать git push --force (для одного не критично, в толпе лучше использовать --force-with-lease.

Или есть еще вариант - лепить к предыдущему коммиту сразу с помощью git commit --amend

Ну и после merge уже можете на master лейбл версии повесить.

попробуйте почитать про методологию БЭМ

Что это?

Это нормальная ситуация.
Зачем платить больше, если можно меньше?

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

Ну всё, хорошие разработчики перестали быть дефицитом) Смиритесь, это рынок. Современное программирование по сложности можно сравнить с инженерным делом, т.е. по сути ничего сложного здесь и нет. А задротов и самоучек хватает.

Такое можно реализовать на уровне веб-сервера (NGINX)
server_name ~^(?<user>.+)\.site\.ru$;
Далее вам будет доступна (на уровне nginx) переменная $user значение которой можно передать в php
fastcgi_param USER $user;
Она будет доступна php в массиве $_SERVER

__init__ это обычный конструктор, __call__ вызов объекта как функцию. Изначально необходимо понять, что все в питоне является объектом в том числе и функции, поэтому метод __call__ есть и у функций. Этот факт очень легко проверить:

>>> def name():
...     pass
...
>>> dir(name)
['__call__', ...

Если вы создадите класс с методом __call__ и создадите объект, у вас объект "превратится" в функцию. Например:

>>> class Name(object):
...     def __call__(self, first, second):
...         return first + second
...
>>> f = Name()
>>> f(1,2)
3
>>>

В питоне нет магических методов (как их принято называть в пхп). Есть например методы для перегрузки операторов (__getitem__, __setitem__, __index__), протокол итерации (__iter__, __next__), протокол контекстных менеджеров (__exit__, __enter__), управляемые атрибуты (__getattr__, __setattr__, __slots__, __getattribute__), протоколы дескрипторов (__get__, __set__, __delete__) ну и т.д. :)

P.S. как всегда рекомендую Лутца, там все очень подробно расписано

Холиварная тема.
Кому-то зайдет.
Лично мне не нравится работа со стилями.
Я уж лучше по старинке через gulp всё сделаю.

// EDIT July 2016

webpack восхитителен

Кошельки, работающие с Bitcoin появились спустя длительное время после того, как появился сам биткоин.

Самая первая версия программы - это и был кошелёк и сейчас вы его так же можете поставить, вот только потребуется более 100 GB для синхронизации всей истории. Через некоторое время стали появляться альтернативные реализации кошельков, в том числе лёгкие, которые выкачивают минимум данных из сети. Но это всё были клиенты для ПК. Еще чуть позже появились сайты кошельки, у которых уже всё синхронизировано - работают быстрее всего и наименее надёжные в плане безопасности. Параллельно сделали хардворные реализации и запилили версии под смартфоны.

А что за криптовалюты без офф кошельков и почему вы считаете, что они достойны упоминания?

Кошельки, работающие с Bitcoin появились спустя длительное время после того, как появился сам биткоин.

Неправда.
Кошельки появились до момента появления биткойна.
Собственно кошелек это хранитель копии блокчейна - основы биткойна.

Как создавать и управлять bitcoin или другими криптовалютными адресами без кошельков?

Никак.

Что должно быть в современном легком блогодвижке?

В нем должен быть «вордпресс» и еще пара каких-нибудь уникальных фишек.