1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

Данный же топик задумывался как непосредственное введение в работу с git, нечто
среднее между tutorial и обобщенной справкой, до которого все же рекомендуется
прочитать упомянутое выше введение. Сознательно избегаются технические
подробности работы git, употребляются только общие для СКВ термины и
ограничивается список упоминаемых команд.

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

Недавно, делая очередной функционал на одном из проектов, я столкнулся с немного необычными связями в реляционных СУБД, у которых, как оказалась позже, есть замысловатое название — Полиморфные связи. Что это такое, как и где их применять, я попытаюсь объяснить в данной статье.

Тема полиморфных связей уже поднималась не раз на Хабре («Rails и полиморфные связи», «Полиморфные сквозные ассоциации в Ruby on Rails», «Полиморфные связи»), но поднималась она в контексте Ruby, и для тех, кто уже имеет какой-то опыт в проектировании БД. Новичкам же (мне было), мало что понятно из тех статей, поэтому в данной статье я попытаюсь рассказать всё на пальцах, абстрагируясь от языка, разве что немного задену ORM популярных фреймворков в вебе.

Часть 1

Процесс оптимизации

Установить в организации хорошо прописанный и формальный процесс оптимизации – это очень полезная практика, поскольку она:

1. организует рабочий процесс и задаёт реальные сроки окончания
2. устанавливает стандарты контроля качества и уменьшает количество ошибок
3. добавляет веса всей операции – логику процесса можно объяснить владельцам компании

На общем уровне планирования я бы рекомендовал устраивать совещания по планированию оптимизации 1-2 раза в неделю, на которых необходимо:

1. Просмотреть текущие тесты, чтобы понять, нужно ли их остановить или признать «завершёнными» (см. ниже). Для законченных тестов есть две возможности:
   
   1. есть явный победитель. В этом случае необходимо разработать его вывод в продакшн
   2. нет явного победителя в текущей контрольной группе. В этом случае нужно определить, требуется ли дополнительное изучение вопроса, или же нужно просто прекращать эксперимент.
   
   
2. Рассмотреть источники данных и подумать над новыми идеями для тестов
3. Обсудить и назначить приоритет любым новым идеям.

Как же понять, когда тест завершён?

Критерии завершённости – вещь сложная и даже являются коммерческими секретами. Определю минимальные необходимые условия для объявления теста «завершённым». Общепринятых стандартов не существует, и критерии зависят в основном от представлений вашей команды. Мы для себя выработали следующие критерии:

Всем привет. У Sublime Text 3 есть замечательный плагин Sublime Linter, который позволяет делать проверку кода на наличие синтаксических ошибок. Промучился я как-то с настройкой этого SublimeLinter, аж три дня. Но всё таки мои мучения прошли не зря и теперь Sublime на лету проверяет синтаксис в HTML, CSS, PHP и JS файлах. Вроде бы всё подробно расписано на различных форумах, а он в некоторых случаях не работает — и всё, хоть убей. Поэтому я и пишу эту статью, чтобы охватить всё и сразу.

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

За последние несколько месяцев я сделал несколько доработок для JSHint, в основном с целью изучить ES6 (я особенно горжусь тем, как переделано обнаружение областей видимости для переменных). Во время этого процесса я наткнулся на несколько вещей, которые меня удивили — в основном, в ES6, однако есть и кое-что про ES3, что я до этого никогда не использовал.

Break из любого блока

Наверняка вы знаете, что в любом цикле можно использовать ключевые слова break и continue — это стандартная возможность в современных языках программирования. Однако не все знают, что циклам можно давать метки и с их помощью прерывать любой конкретный цикл:

outer: for(var i = 0; i < 4; i++) {
    while(true) {
        continue outer;
    }
}

Привет, Geektimes! Сегодня я хочу рассказать об одной штуковине, которая меня здорово выручила и помогла «починить» беспроводную сеть дома у родителей.

^{Картинка из комментариев к посту apcsb на Хабре про неочевидные нюансы WiFi}

Началось всё с того, что один из провайдеров подключил очень-очень много квартир в доме и каждому повесил WiFi роутер в прихожей, вне зависимости от того, нужен он там или нет. Просто всем по сплиттеру оптики в витую пару, роутеру и выкидышу на телефонную розетку, пользуйтесь. В результате 2.4 ГГц диапазон оказался загажен настолько, что о 40 МГц полосе и думать не приходилось…

Привет, Хабр!

В феврале мы публиковали перевод крутой статьи "Почему научиться программировать так чертовски тяжело?", которую теперь показываем новичкам. Да, научиться программировать – это целая история, длинная, с кучей разных этапов, с эмоциональными взлетами и падениями. Мы все через это проходили (или еще проходим – так держать!).

К сожалению, нет такого момента, когда можно встать и заявить, что «я закончил обучение и теперь я программист!». Учиться придется всю жизнь, и всю жизнь вы будете встречать неведомые проблемы, сталкиваться с совершенно непонятными ситуациями и спрашивать «какого хрена?!» даже будучи профессиональным программистом с многолетним стажем.

Сегодня мы публикуем перевод заметки «Почему программировать так тяжело?». Тем, кто еще изучает основы программирования и разработки будет полезно узнать, что их ждет в будущем. А опытным разработчикам будет просто приятно взглянуть на реальность и покивать головой.



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

Вначале я думал, что программировать – это только указывать компьютеру, что делать, эта часть процесса относительно лёгкая. После двадцати с лишним лет опыта, я действительно пришёл к выводу, что эта часть программирования достаточно лёгкая.

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

Не претендуя на библию или «настольную статью программиста» я хочу поделиться полезными находками в моей любимой IDE, не скатываясь в тупую копипасту мануалов и скучных списков хоткеев, только то, что я сам использую постоянно и над чем удивляются коллеги: «о! а так можно?»

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

Вторая часть серии статей посвящена одному из самых сложных и объемных вопросов о современном PHP — что такое «callable»? Я постарался свести в один текст некий минимум знаний об этом вопросе.

Оптимизация веб-сайтов, известная под именем А/Б тестирование набрала популярность в качестве рабочей техники для многих команд, создающих сайты. Но до сих пор по ней слишком мало всеобъемлющих книг, статей или обучающих материалов, направленных на одиночных разработчиков, стремящихся ввести эту технику у себя в организации.

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

Основы: что такое оптимизация веб-сайтов?

Это метод экспериментов, проверяющих, какой дизайн лучше подходит для вашего сайта. Идея проста:

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

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

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

1. Жесты вместо кликов

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



В 2015 прокручивать проще, чем кликать. На мобильном можно делать прокрутку большим пальцем. А попасть точно в цель тяжелее – ровно наоборот по сравнению с десктопом.

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



Эта тенденция продолжится, поскольку мобильных устройств становится больше. На современных сайтах меньше мест для кликов, и больше прокрутки. Меньше ссылок, больше кнопок, больших кликабельных областей и высоких страниц, которые надо прокручивать.

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

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

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