При сборке приложений под iOS для оптимизации ресурсов используется скрипт iphoneos-optimize из набора XCode. Работает он отлично, но если копнуть поглубже, то становится ясно, что некоторые файлы не пережимаются, а другие хоть и немного уменьшаются, но все-равно далеки от идеала. Можно сказать, что задача скрипта сделать файлы более совместимыми с iPhone, чтобы они быстрее читались или распаковывались, но скорее всего это имело смысл лишь на старых iPhone 1 и иже с ними, а уже на процессорах 1ГГц с ARM 7 это откровенно не актуально.
С помощью простых оптимизаций и парочки программ из набора MacPorts можно добиться существенного уменьшения PNG и JPG картинок в конечной программе, а при желании и других видов данных.

В соответствии с календарем релизов осталось всего несколько недель до заморозки списка фич следующего релиза git (1.7.10), в который войдет улучшение работы git merge, нарушающее обратную совместимость и ставящее «под удар» тех, кто использует merge в своих скриптах.
Мы решили последовать совету Джейка Эджа (Jake Edge): «Большинство свободных проектов обсуждают планируемые изменения до их реализации и дают пользователям возможности протестировать новые фичи задолго до релиза. Лучшая помощь проекту на этом этапе — четко обоснованные, конкретные описания существующих проблем, отсутствующей функциональности и т.д., а не бесконечный поток сообщений „Project XYZ ОТСТОЙ!!!11“ в списках рассылки или комментариях»

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

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

С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.

Введение

Это руководство описывает правила для оформления и форматирования HTML и CSS кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

Это относится к рабочим версиям файлов использующих HTML, CSS и GSS

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

Достаточно вольный перевод заметки 7 reasons why angularJS rocks.


Я backend-разработчик и мир Javascript фреймворков для меня достаточно нов, хотя в последние полгода мой интерес к ним сильно растет. Причина проста: я считаю, что стек технологий REST + JSON + Rich JS все больше подходит для широкого круга веб-приложений. Такой подход помогает победить дерьмовую сомнительную концепцию MVC в серверных приложениях. Почему MVC можно считать вредным — это отдельная история, сейчас лучше поговорим об AngularJS.

Что в AngularJS особенного?

Two top Google engineers leave — to Benchmark Capital

В 2007 этим парням было по 26 лет, они проработали в Google 3-4 года, успев стать там одними из лучших.

В то же время, некоторые наши компании дают запросы типа «на проект нужен middle аналитик с 5-6 годами опыта в нашей компании». При том, что офис, в который вы передаете такой запрос, существует всего 4 года, а проекты у нас таковы, что хорошему аналитику уже через год заниматься ими становится скучно.

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

Давайте поговорим об этом.

Зачем?

Вопрос “Зачем?” — самый главный при принятии любого решения. В нашем случае причин было несколько.

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

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

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

Во-вторых, задачи. Возьмем проект Почта@Mail.ru. Мы не можем отказаться от шаблонизации на сервере – нам нужна быстрая загрузка при первом входе. Мы не можем отказаться от шаблонизации на клиенте – люди должны видеть высокую скорость реакции на их действия, а значит, обязателен AJAX и шаблонизация на клиенте.

Проблема очевидна: два набора совершенно разных шаблонов на сервере и на клиенте. А самое обидное, что решают они одну и ту же задачу. Дублирование логики нас просто измотало.

v8 — это интерпретатор JavaScript, а значит, мы можем получить один шаблон, который работает как на сервере, так и на клиенте.

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

Здравствуйте, уважаемые хабражители. Постов про пользовательские скрипты (userscripts) было на хабре немало, тем не менее, они только показывали, как ими пользоваться. А в работе юзерскриптов достаточно много кроссбраузерных несовместимостей (как и в любой области браузерного js). Естественно, можно установить различные дополнения для разных браузеров, однако, в случае написание скрипта для конечного пользователя, придётся сопровождать его огромным readme по установке компонент для обеспечения нормальной его работы. Что лично меня, да и вас, полагаю, тоже, не очень-то устраивает.

В данной статье речь будет вестись о трёх браузерах: Mozilla Firefox (с установленным GreaseMonkey), Google Chrome, Opera. Целью статьи является «заготовка», которая позволит пользовательскому скрипту работать одинаковым образом во всех перечисленных браузерах. Реализация GM API рассматриваться не будет, т.к. таковых уже сотни. Предполагается, что читатель уже знаком с общими правилами написания юзерскриптов (в случае, если нет, рекомендую сначала прочитать другую статью).

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

Однажды в одном большом-большом городе, в одной большой-большой ИТ-компании тестировали один большой-большой проект в одном очень используемом браузере. И обнаружили там утечки памяти. Большие-большие. Прям незадолго до релиза.

И было бы это неудивительно, если бы разработчики были совсем глупые. Но нет же, разработчики наизусть знали «Understanding and Solving Internet Explorer Leak Patterns». Циклические ссылки разрывали, замыкания не использовали, к событиям относились с должным почтением и удалять обработчики не забывали. Да вот только от утечек это не спасло.

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

Особо вероятно изобретение велосипеда, когда рост сложности приложения происходит постепенно и в некотором смысле незаметно. Сложное приложение обычно является богатым приложением (rich), его элементы и особенности специфицированы W3C www.w3.org/TR/backplane. Известный JavaScript-евангелист Addy Osmani так дополнительно определяет сложное приложение: “По-моему, крупное JavaScript приложение есть нетривиальное приложение, требующее значительных усилий разработчика для поддержки, причем наиболее сложное оперирование обработкой и отображением данных ложится на браузер” (http://addyosmani.com/largescalejavascript/).

Сегодня начал верстать очередной сайт и по привычке пошел на www.yaml.de, чтобы скачать самую свежую версию моего любимого CSS-фремворка и… не узнал внешний вид сайта.

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

Я не люблю CSS. Он простой и понятный. Это движущая сила Интернета, но он слишком ограниченный и им трудно управлять. Пришло время привести этот язык в порядок и сделать его более полезным, используя динамический CSS при помощи LESS.
Объясню свою позицию на примере. Почему бы вместо использования #FF9F94 для получения темно-персикового цвета просто не хранить значение этого цвета в переменной для её последующего использования? Что бы перекрасить сайт достаточно будет изменить значение переменной всего в одном месте и всё.
Другими словами: это будет очень изящно, если мы будем использовать немного программирования и логики в CSS, что бы сделать его более мощным инструментом. Хорошо, что это всё возможно с использованием LESS.

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

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

А если вам просто понравилась девушка с картинки, то здесь хайрез :)

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

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

Часто стоит задача, ограничить возможность ввода букв в поле input. Во многих источниках предлагают это сделать следующим способом, навесить обработчик события keyup, со следующим кодом:

return ((event.keyCode>47)&&(event.keyCode<58))

Этот метод обладает рядом недостатков, к примеру также пользователь не сможет вводить цифры numpad, в опере не будут работать клавиши tab,up,left и т. д.
Как же сделать правильно?

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

Смысл сего действа для меня, например, тайна великая за семью печатями есть, ибо я не понимаю, зачем запускать Vim на устройствах без клавиатуры, но может кому-то будет полезно. Вопрос о целесообразности запуска Vim'a на телефоне также остаётся открытым.

Исходники лежат на GitHub и распространяются под той же лицензией, что и Vim.

Эффект кинетической прокрутки сейчас можно встретить практически везде. Это действительно удобно при управлении пальцами или стилусом и довольно забавно при прокрутке мышкой.

В вебе такой эффект пока только приживается. Да и не так уж просто придумать, где он будет удобен… В голову приходят пожалуй лишь scroll bar’ы, которые используются для прокрутки некоторого контента, в основном картинок, внутри страницы. Для примера, можно посмотреть реализацию галереи практически на любом сайте. Согласитесь, было бы значительно интереснее, если бы ползунок не останавливался сразу, как только отпустили кнопку мыши, а продолжал бы двигаться дальше по инерции, постепенно останавливаясь…
Я попытаюсь рассмотреть процесс создания такого эффекта «кинетического» scroll bar’a. Что получилось в итоге можно посмотреть здесь

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

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

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

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

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

Инженер из компании Google, автор трёх книг по веб-производительности и оптимизации, Стив Содерс (Steve Souders) опубликовал презентацию "JavaScript Perfomance" о том, какие методы нужно применять, чтобы скрипты меньше тормозили загрузку страниц.

По статистике WebPagetest, блокировка загрузки файлов .js на сайтах из Alexa Top 100 снижает среднее по медиане время загрузки страницы c 3,65 с до 2,487 с, то есть на 31%. Если вы видите медленную загрузку веб-страниц и хотите улучшить этот показатель, то, по мнению Стива Содерса, первым делом нужно посмотреть на JavaScript.