Igor Karachentsev

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

Воркфлоу - ты создаешь отдельную ветку, вносишь там изменения, после чего вливаешь её в главную ветку.

Начало новой ветки

git checkout master
git pull
git checkout -b название_нового_бранча

Коммит:

git add . добавь все в свою локальную репу

закомить git commit -m “some commit message”…

пушни свою ветку в репу git push origin название_твоей_ветки

название можно чекнуть в IDE (справа снизу) или через git status

Финальный мердж

git checkout master
git pull origin master
git merge название_твоей_ветки
git push origin master

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

UPD
Приведу немного аргументации и очевидных вещей для тех, кто не понимает почему ответ именно такой. На самом деле все очень просто: в IT индустрии все развивается и меняется очень, очень-очень быстро. И как следствие возникает проблема устаревания знаний и умений. Вот например 15-20 лет назад изучение языка программирования под названием "Дельфи" и популярной тогда его среды разработки для дестктопных приложений вполне имело смысл и было популярным явлением, т.к. оно тогда довольно широко использовалось, или например Perl для создания сайтов. А где оно сейчас? Почему сегодня сайты пишутся на джаваскрипте? А как на счет десктопных приложений? А ведь те же десять лет назад попробуй скажи такое — как бы область деятельности не пришлось менять. И вот такое происходит просто с языками программирования за довольно короткое время. А основа любого CMS, фреймворка и иже с ними — это как раз таки язык программирования. И вот за время жизни языка программирования в нём случаются новые стандарты, изменения и прочее, а популярное ПО на нём переписываются десятки и сотни раз. Т.е., изменчивость продуктов какого либо языка зависит как от самого языка так и от его популярности. И чем они выше — тем чаще что-то меняется. Из всего этого вытекает очень логичный вывод: в долгосрочной перспективе выгоднее те знания, которые не устареют как можно дольше. И вот тут как раз таки знания разработки ПО и языков программирования, построения архитектура, алгоритмы и прочее имеют наибольший срок устаревания. А уж сколько тысяч лет математике можно и не вспоминать. А она, кстати именно благодаря стремительному развитию IT тоже развивается очень быстрыми темпами. Так вот, при наличии вот таких фундаментальных знаний можно легко и быстро осваивать любые новые фреймворки, CMS, языки программирования и прочее. А уж при наличии подробных мануалов, гугла, форумов и прочего большинство задач сводится тупо к вбиванию "как сделать YYY в ZZZ" в строке поиска (я вот например никак не могу понять ход мыслей людей, которые задают вопросы на форумах и прочих ресусах, ответ на которые выдается в первых же строчках гугла, складывается впечатление, что они вообще первый раз в интернете и про гугл не знают вообще ничего).
Если есть желание именно в изучении CMS — ставим себе задачу и решаем её используя разные CMS, далее выбираем наиболее понравившуюся и пользуемся пока не надоест или не устареет. А после — повторить.

Немного перефразирую сам вопрос и соседний популярный ответ:
— Каким инструментом учиться пользоваться начинающему строителю?
— Учись использовать молоток и гвозди, леса полно, доски везде используются.
Вот только строительство — это не одни только доски, в которые забиваются гвозди, а еще архитектура, сопромат и иже с ним, экстерьер, интерьер, отопление, освещение, канализация, вентиляция и еще куча всего. Аналогично и во всех остальных областях, в том числе и web разработке.

chown / chmod

Добрый день!

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

flexbox, grid layout

- это css из современных стандартов. Что бы знать, когда применять - вы должны знать версии старых браузеров, которые необходимо поддерживать на вашем проекте, и соответствующую поддержку этих стилей. Например, формировать элементы на flexbox на порядок удобнее, чем на float, но в IE9 вы уже использовать flexbox не можете.
Немного о новинках в css тут.
Поддержка браузерами тут.

gulp, webpack и пр.

- это инструменты, которые созданы для облегчения рутинных задач.
Для верстки очень удобно использовать gulp - вы описываете задачи, такие как создание локального сервера, мгновенная перезагрузка страницы при изменениях, минификация ваших файлов, и прочее.
Посмотрите отличный скринкаст от Ильи Кантора!

препроцессоры

- представьте, что вам чего-либо не хватает в html и css.
Например, вы хотите разбивать большие html файлы на множество мелких, или вам нужно вставить в html динамическое содержание - для этого созданы html шаблонизаторы. Вы используете в работе синтаксис конкретного шаблонизатора, затем тот же gulp автоматически собирает эти файлы в обычный html, который понимает браузер.
Аналогичная ситуация с css, препроцессоры позволяют разбивать файлы на мелкие, и собирать в один, доступны переменные и функции, и многое другое.
Популярный шаблонизатор Pug
Один из css-препроцессоров Stylus

пакетные менеджеры

- это удобный способ скачать конкретные библиотеки, и переносить их из проекта в проект. Статья про npm тут

Ну и конечно статьи и подкасты:
https://habrahabr.ru/
jsraccoon.ru

https://soundcloud.com/web-standards
https://radiojs.ru/

Конкретные статьи и ресурсы для новичка:

frontender.info/a-baseline-for-front-end-developers
frontender.info/a-guide-to-flexbox
css-live.ru/articles-css/pravilnye-kontrolnye-toch...
https://medium.com/russian/%D0%BE%D1%82-%D0%BD%D1%...
https://medium.com/russian/%D0%BE%D1%82-%D0%BD%D1%...
https://habrahabr.ru/company/zfort/blog/321214/
https://frontendmasters.gitbooks.io/front-end-hand...

Дерзайте!

Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

Это была база.
Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
- SELinux, chroot
- доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).

А вопросы все изощренней и изощренней.

Так:

    * Текст     

Так:

    * Текст     

По высоте:

         
         
    * Текст     
         
         

Еще по высоте:

<br/>
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;* Текст &nbsp;&nbsp;&nbsp;&nbsp;
<br/>
<br/>

1. Поиграйтесь с неймспейсами.

2. Когда контроллеры в папку хочется пихать — это уже модуль. Сделайте модуль admin и соберите там необходимые контроллеры.

3. view можно складывать по папкам и для контроллеров приложения, и для контроллеров модулей.

https://github.com/Xethron/migrations-generator ?

Думаю Вам должны вот эти статьи помочь!

stackoverflow.com/questions/28782085/yii2-change-j...
stackoverflow.com/questions/27045361/compiling-cus...

Я использую Jenkins как CI систему для стягивания измений из репозитория, проверки их и деплоя на девелоперский или на продакш сервер.

Но для 1-2 сайтов это немного громоздкая система. Самое то, если у вас 10ок проектов и больше.

Событийная модель помогает строить слабосвязанную систему. Пример из жизни. Я сейчас работаю над SAAS платформой. Компания покупает учетку и выбирает за какие модули платить. Есть модули учета, проверок, для кадровиков и т.д. Модули должны взаимодействовать между собой, но любого модуля может не быть.

Например при создании сотрудника в модуле "кадррезерв", его автоматически надо добавить в модуль "учета". Я не могу напрямую дергать метод из другого модуля т.к. заранее не известно, будет он куплен или нет.

Вместо этого я бросаю событие типа user.created, а в модуле учета в обработчике этого события заношу пользователя в нужные списки. Получается, если модуля нет, то событие просто выброситься в холостую, а если есть, то запустится обработчик.

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

Я РНР-разработчик, не так давно решил разобраться с рельсами. Сейчас я назову несколько абсурдных вещей, которые в общем-то являются достоинствами, но есть некоторые проблемы...

Для клиента:
1. Нету вордпресса. Да! Как только вордпресс перепишут на руби, его сразу начнут использовать все, кому не лень:)
2. А можно мне сайт на джумле? Просто у нас контент-менеджер уже привыкла к её админке.
3. А почему хостинг стоит 200 рублей? У меня сосед по офису вон за 40 купил.
4. "Нет уж, лучше я найму этого пацана за 3 доллара в час, который мне всё сделает, чем вон того говнюка за тридцатку, который говорит про какой-то руби, что это вообще такое? Мне просто нужен сайт на вордпрессе."

Для программиста:
1. А где фигурные скобочки?
2. Магия. Очень много магии. Оно всё делает "само", вплоть до квази-версионирования базы данных по датам. К этому надо привыкнуть, что не все готовы делать.
3. У меня заняло два дня, чтобы смочь подключиться к mysql. Возможно, я не самый опытный программист, но обилие вопросов на stackoverflow и не только наводит на мысль, что половина желающих отсеялась на этом этапе и пошла ставить вордпресс.

Нувыпонели. Недостаточно популярная (чтобы с энтузиазмом приниматься заказчиками) технология с непривычным для многих подходом и вообще синтаксисом языка (чтобы с энтузиазмом приниматься программистами). И ещё на ней нет вордпресса.

А, кстати.

Почему еще НЕ ВСЕ сайты делают на Rails?

Просто на них вордпресса нет.

P.S. ненавижу вордпресс, если что.

Есть программно аппаратные комплексы для низкоуровневой работы с HDD, вроде PC-3000 и подобных.

А то такое ощущение, что развитие восстановления данных остановилось году в 2012-м.

- на самом деле все просто:

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

Современный hdd это сложное электронное устройство которое воспринимает команды на запись и чтения данных от компьютера, и ничего более. Низкоуровневые команды можно давать только подключившись напрямую к контроллеру диска, а не через стандартную SATA шину. Да и то не всегда.

Современный ssd это вообще компьютер, имеющий процессор, оперативную память, внутренний накопитель, и он воспринимает только стандартные команды чтения и записи. И нельзя даже точно сказать куда он что запишет, это все он самостоятельно решает.

Разверните демо магазин битрикса. Там уже есть живой поиск (компонент bitrix:search.title) и возьмите его за основу, просто кастомизировав поисковый индекс, добавив в него нужные поля ИБ.