Веб-разработка *

Удачная возможность для веб-разработчиков выучить язык программирования Си — HTML5-парсер Gumbo, реализованный в виде небольшой библиотеки C99 без внешних зависимостей. Парсер создан как строительный блок для создания других инструментов и библиотек, таких как валидаторы, языки шаблонов, инструменты рефакторинга и анализа кода.

Особенности:

• Полная совместимость со спецификациями HTML5.
• Устойчивость к некачественным входным данным.
• Простые API, которые могут быть легко обработаны программами на других ЯП.
• Поддержка исходных позиций и указателей в оригинальном коде, при навигации по дереву зависимостей.
• Проходит все тесты html5lib-0.95.
• Проверен на более чем 2,5 млрд страниц в индексе Google.

Сколько уже было сломано копий о задачу выравнивания элементов на странице. Предлагаю вашему вниманию перевод отличной статьи с решением этой проблемы от Стефана Шоу (Stephen Shaw) для Smashing Magazine — Absolute Horizontal And Vertical Centering In CSS.

Все мы знали о margin: 0 auto; для горизонтального центрирования, но margin: auto; не работало для вертикального. Это можно легко исправить, просто задав высоту и применив следующие стили:

.Absolute-Center {
  margin: auto;
  position: absolute;
  top: 0; left: 0; bottom: 0; right: 0;
}

Я не первый, кто предложил это решение, однако такой подход редко применяется при вертикальном выравнивании. В комментариях к статье How to Center Anything With CSS Simon ссылается на пример jsFiddle, где приводится отличное решение для вертикального центрирования. Вот еще несколько источников на эту тему.

Рассмотрим способ поближе.

От переводчика

Это перевод статьи Drew Crawford «Why mobile web apps are slow», опубликованной 09 июля 2013. Статья очень интересная, но большая — ошибки возможны — прошу простить и присылать замечания в личку.
Поскольку затронута острая тема, прошу заметить, что переводчик не обязательно разделяет мнение автора статьи!
При переводе текст слегка видоизменялся, поскольку прямой перевод не всегда понятно передает смысл. Для перевода термина «native code» был использован англицизм «нативный код», который понятнее и короче, чем «родной для платформы код». Термин «word processing» переводится как «верстка текста», хотя это немного сужает первоначальный смысл. Термин managed код («управляемый код») не был переведен, так как удачного перевод (на взгляд переводчика) не существует. Под «терминированием» приложения подразумевается его принудительное завершение операционной системой.
Повествование в статье ведется от первого лица: автора статьи.

Присылает нам заказчик (Газпром) свою версию договора.
Понимаем — нашу они не подпишут,
вносим реквизиты и отправляем обратно.
Пропадают на две недели… возвращают протокол разногласий к договору.

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

Как же все-таки работает HTTPS? Это вопрос, над которым я бился несколько дней в своем рабочем проекте.

Будучи Web-разработчиком, я понимал, что использование HTTPS для защиты пользовательских данных – это очень и очень хорошая идея, но у меня никогда не было кристального понимания, как HTTPS на самом деле устроен.

Как данные защищаются? Как клиент и сервер могут установить безопасное соединение, если кто-то уже прослушивает их канал? Что такое сертификат безопасности и почему я должен кому-то платить, чтобы получить его?

Чуть больше четырёх месяцев назад Дженнифер Девальт (Jennifer Dewalt) приняла важное решение — научиться программировать. Хотя у неё не было опыта в этом деле, она никогда не посещала технических спецкурсов в школе, а наоборот — увлекалась только искусствами, но девушка сразу же решительно взялась за дело.

Дженнифер установила правило, что каждый день будет делать по одному веб-сайту, без выходных. При этом каждый веб-сайт должен сопровождаться новой записью в блоге, а весь код выкладываться на Github. Сегодня наступил 115-й день её марафона.

Никогда не планируйте

Проект, как правило, делается сам собой, вырастает, как дерево: главное — вовремя посадить семена и удобрить почву. Разве вы когда-нибудь встречали чудака, который будет прикидывать, насколько вырастет за год дерево, которое он посадил? Правда в том, что планирование никогда еще никому не помогло сделать хороший проект. Точные сроки — это лишняя ответственность и ненужная головная боль. Диаграммы Ганта — для слабаков. Забудьте о них.

Yaxy — proxy-сервер, подменяющий различные части HTTP-запросов и ответов на указанные в config-файле значения. Я не буду здесь описывать, как поставить, настроить и запустить сервер, это всё описано в readme репозитория. Здесь я опишу различные случаи, в которых Yaxy очень помогает, а то и вовсе незаменим.

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

Дисклаймер

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

Проверяем хабр

Единственное упоминание о парадоксе Кондорсе (не путать с теоремой Кондорсе о жюри присяжных) есть в комментарии пользователя TimTowdy.

Ранним утром программист спросил великого мастера:
— Я готов писать модульные тесты. К какому покрытию кода я должен стремиться?
Великий мастер ответил:
— Не переживай о покрытии, просто пиши хорошие тесты.
Программист улыбнулся, поклонился и ушел.

Немного времени спустя другой программист задала этот же вопрос. Великий мастер указал на котел с кипящей водой и сказал:
— Сколько зерен риса я должен положить в этот котел?
Программист с озадаченным видом ответила:
— Как я могу ответить наверняка? Все зависит от того, сколько людей вам надо накормить, насколько они голодны, какие еще блюда вы подаете, сколько риса у вас есть и от многого другого.
— Совершенно верно. — сказал великий мастер.
Второй программист улыбнулась, поклонилась и ушла.

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

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

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

Что же это за проблемы?

«Качество появляется только тогда, когда кто-нибудь несёт ответственность лично».
— Фредерик Ф. Брукс



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

Предлагаю вашему вниманию вольный перевод эссе "A Generation Lost in the Bazaar" Пола-Хеннинга Кампа, повествующего нам о печальной судьбе поколения IT-профессионалов, выросших в период бума доткомов, а также о фундаментальных проблемах в UNIX, напрямую влияющих на качество и портабельность ПО. Обо всём по порядку.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

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

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Моя стажировка в Microsoft Windows Azure началась ровно два года назад, сразу после колледжа, и проходила она в той же команде, с которой я проработал последние восемь месяцев.

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

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

Итак, поехали.

JavaScript принято считать прототип-ориентированным языком программирования. Но, как ни странно, этим подходом практически никто не пользуется: большинство популярных JS-фреймворков явно или неявно оперируют классами.
В этой статье я хочу рассказать об альтернативном способе программирования на JavaScript, без использования классов и конструкторов — чистым прототипным ООП и особенностях его реализации на ECMA Script 5.

По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
Дядюшка Боб

В последнее время меня стали очень утомлять оживлённые дебаты о том, нужно ли комментировать код. Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!». По другую — умудрённые опытом сеньоры. Они понимают, что если возможно обойтись без комментариев, то «Лучше бы, чёрт возьми, так и сделать!». Наверное, у многих жажда комментировать идёт со студенческой скамьи, когда товарищи преподаватели заставляли комментировать каждую строчку, «чтобы студент лучше разобрался». В реальном проекте не должно быть кучи комментариев, которые только и делают, что засоряют код. Впрочем, я не агитирую вообще не писать комментарии, но если вам удалось написать такой код, который не требует пояснений, то расценивайте это, как свою маленькую победу. Сразу хотелось бы сослаться на нескольких очень умных книжек, на основе которых формировалась моя позиция. Я люблю и уважаю авторов этих работ, полностью разделяя их мнение.

• С. Макконнелл, «Совершенный код. Мастер-класс»
• Р. Мартин, «Чистый код. Создание, анализ и рефакторинг»
• Д. Босуэлл, Т. Фаучер, «Читаемый код, или Программирование как искусство»

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Как получить должность инженера в Google, не имея высшего образования?
Вот вам небольшая история.

Один из программистов компании Microsoft анонимно выступил на форуме Hacker News и выдал интересные подробности о процессе разработки ядра NT. Своим сообщением он хотел подтвердить тезис о том, что ядро неэффективно и во многом уступает по производительности другим ОС: см. оригинальное сообщение (автор удалил его, испугавшись резких формулировок) и копию.

Причина проблем, по словам сотрудника Microsoft, социальная. Дело в том, что разработчики не вносят в ядро таких оптимизаций, которые мы видим в мире Linux. В компании Microsoft никто не будет хвалить программиста, если он оптимизировал какой-то процесс на 5%, если это не входит в сферу его основных обязанностей. Такая оптимизация никому не интересна. Только в случае какого-то очень существенного прогресса работу программиста могут заметить в соседних командах разработки, что положительно отразится на его карьере. Но это скорее исключение, чем правило. Нет никакого стимула принимать изменения из-за пределов своей команды разработки.