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

---

Есть один интересный подход при разработке проектов, который мне в последнее время стал нравиться. Суть простая: когда вы пишете функции — кладёте каждую из них в свой отдельный файл. Я сейчас имею ввиду те функции, которые используются во многих местах вашего проекта, формируя таким образом некоторую "библиотеку" методов.

Мало кто поступает таким образом в современном мире. Какие же профиты от такого подхода? А вот какие.

Красивые url'ы на любую функцию проекта

Многие из вас скорее всего неоднократно отправляли друг другу ссылки на различные отрезки кода на Github'е, вроде такого. Сегодня эта ссылка указывает точно на метод под названием booleanConditional. А вот на что эта ссылка будет указывать спустя пол года — на это мы посмотрим спустя пол года :) Ну, рискну предположить, что через пол года там будет мешанина какого-то совсем другого кода, никак не связанного с booleanConditional.

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

Разве не прелесть?

Это перевод статьи Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP", написанной 30 мая 2016, т.е. совсем недавно. Я полностью согласен с её автором, и сам давно горел желанием написать что-то подобное в последнее время, но у меня не так много опыта с Ruby, поэтому моя писанина не была бы настолько объективна, как писанина человека, который этот опыт имеет, и имеет его в хорошем количестве. А тут на тебе: всё в одном месте уже собрано, и мысли прямо один в один как у меня. Грех не перевести на русский. Также, статья вообще очень хороша как небольшой набор объективного и беспристрастного анализа двух языков современной веб-разработки. В общем, далее — перевод слов автора.

многобукв; нечитал;
В этой статье я рассказываю о некоторых фактах и персональном опыте для того чтобы доказать, что PHP в данный момент живее, конкурентоспособнее, а также имеет менее связанную экосистему, чем Ruby. Я говорю о Производительности, Синтаксисе и Аспектах кодинга, Сообществе и Инструментарии разработчика.

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

Deployer хорош во многих отношениях. Код скрипта для деплоя получается коротким. Написан на старом добром Пыхчанском — то бишь, скорее всего, ставить отдельно какие-то другие инструменты на сервер вам не придётся. Если же и придётся — то PHP обычно устанавливается одной командой на любом сервере. Почему-бы и не заюзать его в своих проектах?

Здравствуй, мой дорогой любитель поработать с Composer'ом, создавая свой очередной крутой проект на одном из модных фреймворков. Или, быть может, ты — фронтэнд-мастер, пишущий сложные штуки на JS и CSS, компилируя их из jsx- и less-файлов, устанавливая библиотеки через Bower, а проект собирая в каком-нибудь Grunt, попутно прогоняя код юнит-тестами и, конечно же, заливая потом всё это на github… Если всё это — часть твоей повседневной жизни, то хвала Всевышнему, поздравляю: ты прошел все эти испытания и даже не сломал себе мозг. Отныне, ты — из числа тех счастливых, потративших не одну неделю, разбираясь в том, как корректно настроить всю эту кучу инструментов, а также, ты — один из тех, кто может доминировать, властвовать и унижать блистать своими знаниями в комментариях Хабра к статьям других, менее проворных и смышлёных коллег по цеху…

Но… быть может, ты — лишь один из тех, кто только мечтает о подобных извращениях манипуляциях мастеров разработки современных веб-приложений?) Тогда я спешу обрадовать тебя: я тут на днях узнал пару полезных вещей и понял, что это — настоящий подарок для начинающих разработчиков. И решил написать эту статью.

Это перевод поста "What's new in CSS selectors 4". Он показался мне интересным, и я решил перенести его на хабрахабр. P.S. Это мой первый перевод, не судите строго, и если увидите какие-то недочёты и ошибки — напишите пожалуйста в личку, я постараюсь исправить ошибки. Далее, со слов автора.

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

CSS-селекторы четвёртого уровня — это следующее поколение спецификации CSS, последняя версия которой была выпущена в 2011 году, пробыв в течении нескольких лет в состоянии черновика.

Так что же нас ожидает нового?

Добрый день всем. Я насчёт комментариев к статьям и их длинных и глубоких веток обсуждений, которыми они часто наполняются. Не знаю, как к ним относятся остальные участники сообщества, но у меня часто начинает плавиться мозг от объемов переписок между участниками и отсутствия возможности хоть как-то снизить этот поток информации.

Потому и был написан маленький юзерскрипт, добавляющий две простых фичи:
1. Возможность свернуть-развернуть ветки обсуждений;
2. При открытии страницы, автоматически будут свёрнуты все комментарии выше третьего уровня, за исключением тех веток, где есть непрочитанные вами сообщения, а также тех случаев, когда вы переходите к какому-то конкретному комментарию в статье через ссылку на него.

Пример нового заголовка комментария, ответы к которому были свёрнуты:


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

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

Много воды лить не буду и перейду сразу к советам.