Эта статья посвящена наиболее часто используемым комбинациям клавиш при работе в командной строке Linux (в основном в командном интерпретаторе bash).

Она точно будет полезна начинающим своё знакомство с Linux и, уверен, пригодится тем, кто уже имеет опыт (не всегда годы практики учат работать быстрее).

Никогда не развивал навыка быстрой печати, но знание не одного десятка hotkey'ев, перечисленных в этом материале, позволяет набирать команды со скоростью мысли.

Я попытался продемонстрировать многие примеры при помощи анимированных gif'ок – иногда несколько кадров больше скажут, чем несколько абзацев текста.

Рассказываем о статистике, которую предоставляют постмастеры от Mail.ru и Gmail.com: зачем она нужна, как интегрирована с сервисом DashaMail.

Подготовка рассылки позади: чтобы подписчики открыли письмо, маркетолог выбрал оптимальные тему, прехедер, время и имя отправителя; чтобы совершили целевое действие – поработал над дизайном и содержанием. Но пользователи не смогли оценить результат, ведь вместо папки «Входящие» рассылка улетела в спам.

У сервисов email-рассылок (ESP) нет информации, в какую именно папку попадает письмо. Если оно не было отклонено СПАМ-фильтром, то оно доставлено. При этом открытия из папки СПАМ не отслеживаются, так как, как правило, в этой папке отключены картинки, а именно по их загрузке трекается прочтение письма.

Чтобы видеть распределение доставленных писем по папкам, следует контролировать свою почтовую репутацию с помощью сервисов аналитики доставляемости – постмастеров.

Врага надо знать в лицо. А в digital-маркетинге нужно знать, какую тактику он применяет и какие результаты получает. Анализ конкурентов полезен на любом этапе развития бизнеса. Если вы только начинаете (или планируете) продвижение в интернете, вы можете узнать:

Изобретатели

Открытие

Законы, теории, принципы и закономерности, полезные для разработчиков

Введение

Законы

Закон Амдала

Вы можете использовать это руководство для различных целей:

• Чтобы понять, что такое Spring Framework
• Как работают ее основные фичи: такие как внедрение зависимостей или Web MVC
• Это также исчерпывающий FAQ (Перечень часто задаваемых вопросов)

Примечание: Статья ~ 9000 слов, вероятно, не стоит читать ее на мобильном устройстве. Добавьте ее в закладки и вернитесь позже. И даже на компьютере ешь читай этого слона по одному кусочку за раз :-)

Содержание

• Введение
• Основы внедрения зависимостей
• Контейнер Spring IOC / Dependency Injection
• Spring AOP (Аспектно-ориентированное программирование) и прокси
• Управление ресурсами Spring
• Spring Web MVC
• Дополнительные модули Spring Framework
• Spring Framework: часто задаваемые вопросы
• Заключение

Введение

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

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

Вы наверняка слышали это знаменитое высказывание от GoF: «Предпочитайте композицию наследованию класса». И дальше, как правило, шли длинные размышления на тему того, как статически определяемое наследование не настолько гибко по сравнению с динамической композицией.

Гибкость – это конечно полезная черта дизайна. Однако при выборе архитектуры нас интересуют в первую очередь сопровождаемость, тестируемость, читабельность кода, повторное использование модулей. Так вот с этими критериями хорошего дизайна у наследования тоже проблемы. «И что же теперь, не использовать наследование вообще?» – спросите Вы.

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

Проблема хрупкого базового класса

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

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

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

Упустить из виду этот принцип, все равно, что признаться в собственной неспособности решать прикладные задачи.

Рассмотрим несколько случаев.

Источник

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

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