Уже совсем скоро мы в AppTractor.ru проводим в Москве конференцию Ladies Code. Цель нашей конференции — поддержать женщин в их стремлении развивать технологии и поделиться лучшими примерами построения успешной карьеры в IT.

Привет, Хаброжители! Мы начали издавать новую серию книг «Pop Science», обзор которых мы сделали на Geektimes.
Здесь мы представим отрывок из книги:

Парадокс Ферми можно сформулировать так.

Поскольку Вселенная настолько велика, ее размеры настолько необъятны и в одном только Млечном Пути светят сотни миллиардов звезд, многие из которых имеют вокруг себя планетар-ные системы, то в случае, если Земля не является в высшей степени нетипичным местом в том, что касается условий для развития жизни, Вселенная должна кишеть такими планетами, в том числе населенными разумными цивилизациями. Многие из них должны иметь технологии, позво-ляющие путешествовать в космосе, и к настоящему моменту они уже должны были посетить нас.
Где же они все в таком случае?

Акварель — чистый С

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

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



Прикладной уровень является самой надежной защитой. Уязвимости, с которыми мы тут встретимся, зачастую полагаются на сложные сценарии ввода данных пользователем, что делает их трудноопределимыми с помощью систем обнаружения вторжений. Этот уровень — самый доступный извне. Для нормального функционирования приложения должен быть доступ через порт 80 (HTTP) или порт 443 (HTTPS).

Продолжение цикла переводов полезных советов для веб-разработчика. Другие части: 1-16, 33-48.

Содержание:
   17.  Быстрое редактирование названия HTML-тега в панели «Elements»
   18.  Разворачивание всех дочерних узлов выбранного элемента
   19.  Переключение состояния вкладки DevTools при помощи горячих клавиш
   20.  Переключение на DOM-элемент из DevTools консоли
   21.  Подсветка выполняемого выражения
   22.  Улучшения в работе инструмента Color Picker
   23.  Включение точки останова и навигация по стеку вызовов при помощи горячих клавиш
   24.  Просмотр определения функции, зарегистрированной как обработчик события на DOM-элементе
   25.  Нотификация о JS-ошибке во время написания кода
   26.  Персистентность настроек отображения для режима «Инкогнито»
   27.  Визуализация выбранного режима сглаживания анимации
   28.  Просмотр и изменения точек останова DOM-дерева при помощи панели «Breakpoints»
   29.  Пять интересных возможностей панели «Console»
   30.  Автодополнение свойств и методов объекта в панели «Console»
   31.  Просмотр и отладка обработчиков событий
   32.  Автоматическая остановка выполнения программы при возникновении любых исключений

Я очень люблю статические типы, поэтому TypeScript стал незаменимым помощником при работе с NodeJS или браузерным JS.

По долгу службы приходится иметь очень много дел с JSON, и здесь система типов TypeScript не помогает ничем, даже мешает, ведь компилятор сообщает об отсутствии ошибок, JSON.parse возвращает тип Any. Кроме того, TypeScript не поддерживает рефлексию, ввиду специфики работы, а значит, нет возможности проверить тип, основываясь на уже существующем коде. Также, до последнего времени, средств для мета-программирования не было вовсе.

Зачастую проверка корректности пришедшего JSON-объекта оборачивается громадным кодом в конструкторах классов, либо такими же конфигурационными файлами. Но, наконец-то, в TypeScript 1.5 появились декораторы.

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

В нашей компании в процессе разработки принято придерживаться нескольких простых принципов. Возможно, кому-то они покажутся спорными, кому-то наивными, но, так же как и календарь, про который писал в прошлом году наш IT-директор (aka paulig), эти принципы — результат собственного опыта и ошибок. Кроме того, мы верим, что следование им даёт возможность решать задачи быстрее и эффективнее.

Зачем это было написано, если есть множество книжек по методологиям разработки (в том числе extreme programming, scrum, tdd), по программированию в целом и в частности, о том, «как пасти котов» и про «идеальный код»? Книг много, но разработчики, к несчастью, их читать не любят. Ну, ладно, любят, но не все. У них, мол, своя специфика. Квинтэссенция нужна. И проще, ближе, понятнее. Вот поэтому. И в жизни чаще всего приходится вспоминать, вернее, не забывать, именно те, которые перечислены ниже.

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

Как это начиналось

Я всю жизнь занимался разработкой под Windows. Сначала на С++, затем на C#. В промежутках мелькали VB, Java Script и другая нечисть. Однако некоторое время назад всё изменилось и я впервые столкнулся с миром Linux, Java и Scala. У нас с Денисом, моим другом и соратником по многочисленным идеям, уже был свой проект – набор утилит для Windows, который пользовался широким спросом в узких кругах. В какой-то момент мы оба потеряли интерес к этому проекту и встал вопрос – что же делать дальше. Денис стал инициатором идеи нового проекта – сервис по обмену clipboard между разными устройствами. Этот проект существенно отличался от предыдущего помимо технологий ещё и целевой аудиторией. Этот сервис должен был стать полезен всем. Скопируйте данные в буфер обмена и вставьте из него на любом другом устройстве. Звучит проще некуда, пока не задумаешься над тем сколько сейчас разных устройств, а также как это все будет работать при большом количестве пользователей.
Первый прототип появился через несколько месяцев. Сервер был написан на ASP.NET и хостился на MS IIS. Было написано 2 клиента: на С++ под Windows и на Java под Android.



Тестирование показало, что прототип держит около 500 соединений. Что же делать, если их будет больше, мы ведь расчитываем на сотни тысяч пользователей ;) Как написать сервер, который может работать с большим количеством соединений, который не надо будет выключать во время апгрейда железа или софта и который будет легко масштабироваться (то есть расширяться в случае увелечения количества пользователей).

В этой статье предлагаю на примере простого массива рассмотреть как именно работают внутренние интерфейсы Traversable и ArrayAccess.

Сразу приведу список ресурсов, на которые далее по тексту будет множество ссылок.

• lxr.php.net — Удобнейший поиск по исходному коду php;
• phpinternalsbook — Полезнейший ресурс по внутренностям php. А конкретно нас интересует раздел по классам;
• Руководство по ядру PHP.

И про платформу: я писал код по ubuntu, так что для других linux дистрибутивов (да и OS X) понадобится минимум изменений (поменять apt-get). Если хотите писать под Windows, то придется поискать информацию в других интернетах (все равно никто не пишет код по windows).

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

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

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



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

Предлагаю читателям «Хабрахабра» перевод публикации «Is ReactJS really fast?» из блога компании 500Tech.

tl;dr; Нет.

Большинство разработчиков считают само собой разумеющимся, что ReactJS — это супер быстрый движок по сравнению
с другими более тяжеловесными фреймворками, такими как AngularJS и EmberJS.

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

Первая часть здесь. Продолжение:

Семь долбаных лет я ждал язык, который хоть как то ответит части моих желаний. За это время, и в фоновом режиме я препробывал всё. Всё — означает, всю херню общего назначения, и всю херню не совсем общего назначения. Нельзя прочувствовать язык только что-то прочитав про него и написав Hello World. Чтобы понять — надо хоть немного попрограммировать — написать какую нить вещь. И вот все это время, я в минуты отчаянья качал какой-нить “замечательный язык”, и пытался что-то написать. Какие-то вещи даже до сих пор крутятся в конторе (или крутились).

Интро

Не так давно я выступал на конференции FrontendConf 2015 (РИТ++) с темой данной статьи. И при подготовке доклада начал искать информацию, а кто вообще выступал на данную тему и что есть в Сети на данный момент.

Оказалось, что информации совсем немного, более-менее можно было бы отметить доклад mikewest.org/2013/09/frontend-security-frontendconf-2013 от Mike West из компании Google, но какой-то «непентестерский» взгляд и уж совсем мало материала. И www.slideshare.net/eoftedal/web-application-security-in-front-end где тема раскрыта более детально, но выступление 2011 года. А за 4 года технологии и атаки на месте не стояли.

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

О чем вообще разговор?

А действительно, о чем тут вообще можно разговаривать? Говоря про взломы и безопасность невольно приходят в голову тезисы — слили базу, получили доступ к выполнению команд ОС на сервере, прочитали чужую переписку. Но это все — server side код. А что ж может «нагородить» фронтэндер? Главная опасность, конечно же, в обходе атакующим SOP — Same Origin Policy, главной политики безопасности браузеров, которая регулирует работу в разных Origin. Но не только, давайте разбираться.

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

Прочитали? Дальше будет про лучший в мире язык программирования, который я назову ближе к концу. Да, да, еще три дня назад я и не думал что единороги существуют — ведь каждый язык так или иначе сосет, и каждый сосет по-своему (хотя нет, есть и такие которые сосут всегда и везде, но о них не будем). Как инженер, я прекрасно понимал что в вопросе языка не возможно без разнообразных trade offs, начиная с garbage collected vs manual memory management, хотя Rust пытается съесть рыбку не присев на палку в этом вопросе, и так далее. Хоть мы и говорим о языках общего назначения, все они так или иначе позиционируют себя, фокусируясь на каких-то идеях, принципах, и целях, в которых они хороши, оставляя все не согласованное с такими принципами в лучшем случае возможными, но не эффективными и/или не удобными. Одним словом нецелесообразными. Однако язык, сочетающий в себе несочетаемое, есть.

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

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

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

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

Начну с нетехнической части.

Оригинал: React To The Future With Isomorphic Apps

Изоморфные приложения. Взгляд в будущее с React

В разработке программного обеспечения все часто возвращается на круги своя. Так, например, на заре развития Интернета серверы подгружали контент сразу же на сторону клиента. В последнее же время, с разработкой современных веб-фреймворков, таких как AngularJS и Ember, мы видим тенденцию к обработке запросов на стороне клиента и использованию сервера только для API. Однако, это далеко не единственная тенденция. Сейчас происходит медленное возвращение или, скорее, слияние этих двух архитектур.

Господа! Я рад сообщить, что наконец-то все желающие могут загрузить бесплатный учебник на более чем 1600 страниц, над переводом которого работало более полусотни человек из ведущих университетов, институтов и компаний России, Украины, США и Великобритании. Это был реально народный проект и пример международной кооперации.

Учебник Дэвида Харриса и Сары Харрис «Цифровая схемотехника и архитектура компьютера», второе издание, 2012, сводит вместе миры программного обеспечения и аппаратуры, являясь одновременно введением и в разработку микросхем, и в низкоуровневое программирование для студентов младших курсов. Этот учебник превосходит более ранний вводный учебник «Архитектура компьютера и проектирование компьютерных систем» от Дэвида Паттерсона и Джона Хеннесси, причем соавтор предыдущего учебника Дэвид Паттерсон сам рекомендовал учебник от Харрисов как более продвинутый. Следуя новому учебнику, студенты строят реализацию подмножества архитектуры MIPS, используя платы с ПЛИС / FPGA, после чего сравнивают эту реализацию с индустриальными микроконтроллерами Microchip PIC32. Таким образом вводится вместе схемотехника, языки описания аппаратуры Verilog и VHDL, архитектура компьютера, микроархитектура (организация процессорного конвейера) и программирование на ассемблере — в общем все, что находится между физикой и высокоуровневым программированием.

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

В наше время для разработки фронтенда существует много фреймворков и библиотек. Есть хорошие, есть не очень. Часто нам нравится только какая-то концепция, модуль или синтакс. Универсальных инструментов не существует. В статье я описываю фреймворк будущего – такой, которого ещё нет. Я собрал достоинства и недостатки известных фреймворков и мечтаю об идеальном решении.

Абстракция опасна

Всем нравится простота. Сложность убивает. Она усложняет работу и приводит к крутой кривой обучения. Программистом нужно понимать, что как работает – иначе они чувствуют себя неуверенно. При работе со сложной системой есть большое расстояние между «я её использую» и «я знаю, как это работает». К примеру, следующий код прячет сложность:

var page = Framework.createPage({
	'type': 'home',
	'visible': true
});

Допустим, это реальный фреймворк. createPage где-то создаёт новый класс Вида, загружающий html-шаблон home. Основываясь на параметре visible мы добавляем созданный DOM-элемент к дереву. С точки зрения разработчика мы не знаем, как это всё работает в деталях, потому, что это – абстракция.

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

Если мы поменяем пример на следующий:

На прошлой неделе я обновил свои мониторы. Выбросил Apple Cinema Display и на их место взял 4К-мониторы от Dell. Как печатнику, мне понравился предыдущий апгрейд с чёрно-белых до grayscale-мониторов в 90-х годах. Но 4К – ещё лучше. Дисплеи высокого разрешения уже пришли на смартфоны и планшеты. Приятно, что они появляются и у ноутбуков и декстопов. Шрифты выглядят чудесно.

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



Но что есть «4К»? С лёгкой руки маркетологов, это экран размера 3840 на 2160 пикселей (3840 – это ну почти 4000). По каждой из сторон разрешение в два раза больше, чем у HDTV, то есть 1920х1080.

Спервоначалу люди говорили, что у 4К-экранов «в два раза больше пикселей». На самом деле, если вы удвоите количество пикселей линейно, это всё равно, что вы разрежете каждый пиксель как по вертикали и по горизонтали. То есть, на экране 4К в 4 раза больше пикселей, чем у HDTV.

И, что характерно, на этом останавливаться никто не собирается, на горизонте уже дисплеи 7680 х 4320, известные как 8К. С другой стороны, разрешение, воспринимаемое человеческим глазом, имеет границы. Переход на 4К заметен. На 8К – менее заметен. В какой-то момент нужно будет перестать делить пиксели.

Но что, если они не перестанут? Что, если они будут делить пиксели бесконечно? Сколько тогда пикселей будет на экране?

а) по количеству положительных целых чисел
б) меньше
в) больше

Если вам не интересна математика, тогда итог статьи такой: купите 4К-монитор. Не стоит благодарности.