В предыдущей статье рассматривалась теория и практика прогрессивного улучшения (progressive enhancement). В этой статье мы от идеологии перейдем к аксиологии и рассмотрим финансово-экономическую обоснованность применения прогрессивного улучшения.

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

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

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

Привет, меня зовут Игорь (iamo0), я старший фронт-энд разработчик в Островке. Я занимаюсь нашим основным продуктом: сайтом Ostrovok.ru. С помощью нашего сайта ежедневно бронируют отели тысячи человек, поэтому для нас очень важно, чтобы качество нашего продукта было на высоте. А для этого нужно не отвлекаться на разного рода мелочи и уметь эффективно решать поставленные задачи.

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

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

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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

От переводчика: недавно я купил часы с лазерным проектором и прочёл в инструкции привычную фразу: «Запрещено ремонтировать самостоятельно». Раньше в инструкциях писали, что при самостоятельном ремонте производитель отказывается от гарантийных обязательств. Это наглость, но можно понять. Сейчас они прямо запрещают разбирать устройство, даже не объясняя почему. То есть просто выкинь и купи новое. Полный беспредел потребительской культуры.

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

4 года назад я открыл для себя понятие «фриланса» и описал впечатления в статье: habrahabr.ru/post/53938

Думаю, есть смысл поделиться последними наблюдениями.

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

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

Тот дизайнер, который ценит своё время, любит порядок в работе, разукрашивает папки и обзывает слои вменяемыми именами, а иногда даже оставляет «сноски в фотошопе в трудных для понимания местах» мгновенно переходит на следующий уровень с соответствующим ценником. И даже если финансы позволяют вам воспользоваться их услугами – их очень не просто найти, так-как соотношение между «дизайнерами-новичками» и «дизайнерами-со-скиллом-именования-слоёв» стремится к 80% — 20% или даже 90% — 10%.

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

В этой статье собраны полезные  и «правильные» стили и сниппеты, которые помогут ускорить процесс разработки сайта, а также оптимизировать верстку.

Если Вы часто сталкиваете в работе со следующими фразами, то это статья для Вас:
• Почему ты, не разобравшись, сделал такую ерунду?
• Хватит задавать вопросы, прочитай вот этот маленький параграф и всё поймешь! — Я прочитал, но ничего не понял, объясни по-человечески.
• А вы знаете, нам всё надо делать по другому, так как в книге Х, в главе Y, есть утверждение Z противоречащее пункту 14.5.3 нашего ТЗ.
• Когда ты уже начнешь работать? – Я проектирую систему, мне надо ещё три недели.
• У меня есть идея, как сделать нашу жизнь лучше! Вася, послушай меня, тебе надо сделать: а, б, в, г …

Пролог

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

Краткое содержание предыдущей серии: решил учить python, после Лутца и Ника Парланте записался на фундаментальный CS курс (к сожалению, не всегда python style), на легкий курс «Питон для самых маленьких» (уже окончен). Ну и где то между ними я ввязался в CS188.1x AI, рассудив раз уж тренировать питона, так на серьезных вещах.
В предыдущем обзоре я успел рассмотреть первые 2 недели курса (порядка 30%), собственно 19 ноября миновал hard deadline для итогового экзамена, и хочу подвести итоги.

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

Начиная с 2009 года я регулярно публиковал статьи на различную тематику — начиная от освещения Data Mining, разработки для iOS и .NET, заканчивая тем, как писать кандидатскую работу и что из этого может получиться.

Дальнейший карьерный рост (а по большому счету тот факт, что технические статьи на хабре остались в маргинальном меньшистве) мотивировал на написание других статей: Эффект бабочки, Кто хочет, тот ищет возможности, кто не хочет — ищет причины, О мотивации в ИТ, Тренды, возведенные в культ и другие статьи, которые, к моему удовольствию, нашли своего читателя.

Первоисточник: Том ДеМарко “Deadline. Роман об управлении проектами”

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

Это статья об изменениях, которые произошли в мире веб-разработки. Я наблюдаю огромное количество веб-разработчиков, которые буквально застряли в устаревших технологиях, особенно в мире .NET. Если вы еще не начали совершенствовать свои навыки, и адаптироваться к изменяющимся трендам, вы должны начинать уже сегодня.

Статей про SASS(SCSS), Less на хабрахабре уже полно, но на мой взгляд не хватает такой, в которой было бы немного реальной практики. Я постараюсь восполнить этот пробел. Около года назад одна из SASS-статей меня "зацепила", и с тех пор я полюбил эту технологию настолько, что ручной набор обычного CSS кода представляется мне лишней тратой времени. Сия статья посвящается тем верстальщикам (или web-программистам), которые про SCSS ещё не слышали, или же ещё не пробовали в деле. Более опытным товарищам, полагаю, в ней ловить нечего.

Что такое SCSS

SCSS — "диалект" языка SASS. А что такое SASS? SASS это язык похожий на HAML (весьма лаконичный шаблонизатор), но предназначенный для упрощения создания CSS-кода. Проще говоря, SASS это такой язык, код которого специальной ruby-программой транслируется в обычный CSS код. Синтаксис этого языка очень гибок, он учитывает множество мелочей, которые так желанны в CSS. Более того, в нём есть даже логика (@if, each), математика (можно складывать как числа, строки, так и цвета). Возможно, некоторые возможности SCSS покажутся вам избыточными, но, на мой взгляд, лишними они не будут, останутся "про запас".

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

С выходом Sass 3.2 начал продвигаться в массы путь объектно-ориентированного CSS (OOCSS), принося с собой принцип DRY и программистское мышление. Media queries и OOCSS стали жизненно важны для современной фронтенд разработки.

Недавно Крис Койер отвечал на вопросы читателей Smashing Magazine. Один из вопросов был о том, как распознать код CSS с «душком»:

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

Я подумал, что могу расширить и дополнить ответ Криса исходя из собственного опыта.

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

Я хочу поделиться несколькими вещами, на которые я обращаю внимание прежде всего, чтобы составить впечатление о качестве, сопровождаемости и чистоте кода CSS.

Один из американских пользователей Apple купил новый Macbook Pro с дисплеем Retina, но столкнулся с проблемой, которая уже многократно упоминалась на форумах Apple: так называемые «призраки», то есть остаточный эффект от предыдущего изображения на экране.



Например, на фотографии показан серый дисплей, на котором до этого три минуты «горела» фотография Фила Шиллера, Тима Кука и Джонатана Айва.

Это перевод заметки Криса Койера Why Ems? на css-tricks.com.



Я долгое время применял px для установки font-size, из-за чего размер шрифта не мог меняться в Internet Explorer 6-8. Переход на em имеет ряд преимуществ, и в этой статье они детально рассмотрены.

В августе этого года Facebook выпустила новую версию своего приложения для iOS. Оно стало полностью нативным. Это событие привело к новому раунду дебатов по поводу преимуществ нативных приложений по сравнению с HTML5-приложениями. Я тоже хочу высказаться по этому поводу.

Общественное мнение в данном случае весьма поляризовано. Недавно я участвовал в одной дискуссии. Она началась с обеспокоенность одного человека тем, что его компании теперь придется разрабатывать клиент для Microsoft Surface в дополнение к Android и iPad. А закончилась дискуссия высказыванием другого: «А можно использовать HTML5 и разом получить клиента на все три платформы».

Марк Андреессен (Marc Andreessen), влиятельный в сети человек, сказал: «Приложения будущего — это веб-приложения. Все будет жить в сети. Нативные мобильные приложения на платформах вроде iOS и Android — это промежуточный шаг на пути к полностью мобильной сети. Этот временный этап может продолжаться очень долго потому что сети до сих пор ограничены. Но если вы позволите мне сделать смелое предположение, что однажды у нас будет повсеместно доступно высокоскоростное беспроводное подключение к сети, то очевидно, что в конце концов все придет к веб-приложениям. Потому что технология хочет, чтобы все было именно так.»

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

Вопрос

Главный вопрос: насколько толстыми должны быть клиенты?