Автор: Антон Реймер

Статья основана на вебинаре, который я проводил некоторое время назад. Рассчитана она, в первую очередь на тех, кто не знает, как работают браузеры, или тех, у кого есть пробелы в знаниях. Вероятно, здесь будет много очевидного для тех кто не первый день в веб-разработке. Статью я решил разделить на две части. В первой рассмотрим общие принципы работы браузера. Во второй части я акцентирую внимание на некоторых важных моментах: reflow и repaint, event loop.

Что такое браузер?

Браузер — программа, работающая в операционной системе. Большинство браузеров написано на языке C++. Основное предназначение браузера — воспроизводить контент с веб-ресурсов. В качестве веб-ресурса в большинстве случаев выступает html-страница. Это также может быть pdf-файл, png, jpeg, xml-файлы и другие типы. Среди огромного количества браузеров можно выделить самые популярные: Chrome, Safari, Firefox, Opera и Internet Explorer. Мы рассмотрим браузеры с открытым исходным кодом: Chrome, Firefox, Safari.

Из чего состоит и как работает браузер?

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

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

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

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

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

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

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

Добрый день. Последний год я занимаюсь в проекте «МойОфис» вопросами совместного редактирования (collaboration). Оглядываясь назад, могу констатировать, что это непростая и очень интересная задача. Поэтому я хотел бы подробно рассказать о ней и дать ответы на следующие вопросы:

1. Какие существуют подходы к обеспечению совместного редактирования?
2. Насколько они сложны в реализации?
3. Можно ли взять готовую библиотеку и использовать ее в своем проекте?
4. Можно ли вести разработку без оглядки на совместное редактирование?

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

Ранее на этой неделе (статья от 19 июня — прим.) спецификация ES6, официально названная ECMA-262, 6th Edition, ECMAScript 2015 Language Specification, преодолела последний барьер и была утверждена как стандарт Ecma. Мои поздравления TC39 и всем остальным, кто помогал. ES6 закончен!

Даже лучше: больше не надо будет ждать следующего обновления 6 лет. Комитет собирается выпускать новую версию в срок около года. Предложения по ES7 уже примаются!

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

Примечание переводчика: Тема наследования в JavaScript является одной из самых тяжелых для новичков. С добавлением нового синтаксиса с ключевым словом class, понимание наследования явно не стало проще, хотя кардинально нового ничего не появилось. В данной статье не затрагиваются нюансы реализации прототипного наследования в JavaScript, поэтому если у читателя возникли вопросы, то рекомендую прочитать следующие статьи: Основы и заблуждения насчет JavaScript и Понимание ООП в JavaScript [Часть 1]

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

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

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

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

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

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

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

Продравшись сквозь бюрократические дебри, наш компьютерный гений открыл фирму, создал и раскрутил свой сайт, взял пару-тройку заказов… и энтузиазм его несколько поубавился. Потому что на сцену вышел новый персонаж — Его Высочество Клиент. Тот самый, про которого ClientsFromHell, Zadolba.li и проч.

Айтишник — умнейший человек. В технических вопросах, да и не только — настоящий профи. Но кое-чему он научиться просто не мог — а именно: договариваться. А когда? Он провел почти всю жизнь среди более-менее близких людей — семьи, одноклассников, однокурсников, коллег. Тех, кому волей-неволей пришлось принимать его таким, как есть. Ему не приходилось выцыганивать скидку, блефовать с конкурентами, прессовать поставщиков и умасливать клиентов.

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

Очередная поп-психология, «сделайте глубокий вдох и подумайте о вечности»? Нет же! Обе книги написали профессиональные переговорщики: автор первой тренирует антитеррористические подразделения ФБР, авторы второй специализируются на критически важных переговорах в бизнесе.



Итак, два пособия:
Марк Гоулстон — «Я слышу вас насквозь» (в оригинале — «Просто слушай»).
Патерсон, Гренни, Макмиллан — «Есть серьезный разговор».

Продолжение Часть 1, Часть 2

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

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

Новый таскбар Windows 7 отличается не только от дока макос, но также умом и сообразительностью. В частности, он очень обижается, когда к нему хотят прикрепить (pin) что-либо, отличное от .exe файла: скрипт, программу на питоне. Логику разработчиков легко понять: новый таскбар автоматически помещает прикрепляемые документы в контекстное меню программ. Например, если перетащить на таскбар текстовый документ, то к таскбару будет прикреплен notepad, а сам документ будет доступен по правому клику из списка 'pinned items'. К сожалению, у данного подхода есть две проблемы. Во-первых, нужно делать правый клик на иконке — лишнее движение, очень неудобное на тачпадах ноутбуков. Во-вторых, данный способ не работает для многих типов файлов, например — .bat файлов или скриптов на питоне. Гугление, как ни странно, быстрого ответа не дает. Поэтому, уважаемые коллеги, я вкратце законспектировал последовательность шагов, которая позволяет прикрепить к таскбару любой файл и сменить его иконку.

Синоптики предсказывают, что к 2016 году наступит второй ледниковый период трафик в беспроводных сетях на 10% превзойдёт трафик в проводном Ethernet. При этом от года в год частных точек доступа становится примерно на 20% больше.

При таком тренде не может не радовать то, что 80% владельцев сетей не меняют пароли доступа по умолчанию. В их число входят и сети компаний.

Этим циклом статей я хочу собрать воедино описания существующих технологии защит, их проблемы и способы обхода, таким образом, что в конце читатель сам сможет сказать, как сделать свою сеть непробиваемой, и даже наглядно продемонстрировать проблемы на примере незадачливого соседа (do not try this at home, kids). Практическая сторона взлома будет освещена с помощью Kali Linux (бывший Backtrack 5) в следующих частях.

Статья по мере написания выросла с 5 страниц до 40, поэтому я решил разбить её на части. Этот цикл — не просто инструкция, как нужно и не нужно делать, а подробное объяснение причин для этого. Ну, а кто хочет инструкций — они такие:

Используйте WPA2-PSK-CCMP с паролем от 12 символов a-z (2000+ лет перебора на ATI-кластере). Измените имя сети по умолчанию на нечто уникальное (защита от rainbow-таблиц). Отключите WPS (достаточно перебрать 10000 комбинаций PIN). Не полагайтесь на MAC-фильтрацию и скрытие SSID.

Оглавление:
1) Матчасть
2) Kali. Скрытие SSID. MAC-фильтрация. WPS
3) WPA. OpenCL/CUDA. Статистика подбора

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

Basket.js

Basket немного похож на RequireJS, только с его помощью все подключаемые скрипты и стили кешируются в localStorage. Тесты Google и Bing демонстрируют улучшение производительности при использовании локального хранилища по сравнению с обычным браузерным кешем. Проект изначально появился как эксперимент, который полностью оправдал результаты этих тестов.

basket
    .require({ url: 'missing.js' })
    .then(function () {
        // Success
    }, function (error) {
        // There was an error fetching the script
        console.log(error);
    });

Итак Гонконг. Город высоких домов и дорогих гостиниц. Мы здесь, чтобы посетить хакспейс Dim Sum Labs и поработать там пару дней.



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

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

Сервис Transloadit.com запустил новую фичу: обработка видеофайла кодеком ffmpeg в процессе его загрузки на сайт. Серверы Transloadit обеспечивают скорость кодирования выше, чем скорость аплоада у большинства пользователей. Таким образом, теперь практически устраняется задержка между загрузкой и публикацией видеоролика.

Фича realtime-кодирования в некоторых случаях увеличивает «скорость кодирования» (то есть время между окончанием загрузки файла и окончанием кодирования) в 150 раз. Как это работает, показано на видео под катом или можно проверить самому в демо-секции на сайте Transloadit.com.

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

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

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

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



Многие из тех, с кем я говорила, знакомы вам по постам в блоге Яндекса на Хабре: anatolix, kappa, bobuk, yafinder, styskin. Несмотря на то, что многие участники нашего опроса стали руководителями, они продолжают писать код. Под катом можно прочитать подробные ответы, не полностью попавшие в видео, и рассказать, что вы думаете по теме.

Предисловие

Получив в свое распоряжение очередной psd файл, я уже знал список требований к будущему сайту, в одном из пунктов которых числился отзывчивый дизайн. Работу над ним начал с разметки главной страницы и в тот же момент подумал как было бы хорошо не использовать большинству известную формулу (target / context * 100 = result) приведенную в книге Итана Маркотта «Отзывчивый веб-дизайн», а сразу писать ширину каждого блока в пикселях, предварительно замерив ее в Photoshop, при этом получать все в процентах. Мысль мне показалась неплохая и я решил погуглить и попытаться найти что то по интересующему меня вопросу, но, к сожалению, мне не удалось разыскать что либо полезное. Ну, что ж, подумал я, раз нет ничего готового, способного мне помочь, тогда нужно сделать это самому. В данном вопросе я полагался на препроцессор Sass, который уже не раз помогал мне избежать лишней головной боли и строчек кода. К тому же я уже знал о существовании в Sass новых типов данных таких как lists и maps. Первый мне был не интересен, а вот без последнего моя затея потерпела бы краха. Основная идея состояла в том, что мне известна ширина каждого блока и сумма ширин блоков с одним уровнем вложенности равна 100% и если препроцессор позволит мне нужным образом обработать эти данные, то задавая ширину в пикселях, я мог на выходе получить ее в процентах не заботясь о вычислениях.