Pull to refresh
5
0
Send message

Обзор ES6 в 350 пунктах. Часть первая

Reading time 6 min
Views 56K
Моя серия заметок ES6 in Depth, состоящая из 24 записей, описывает большинство синтаксических изменений и нововведений в ES6. В этой публикации я подведу итог всего изложенного в предыдущих статьях, чтобы дать возможность посмотреть еще раз на всё вместе. Также я добавил ссылки на мой блог, чтобы в случае необходимости сразу же можно было посмотреть подробнее.



Я слышал, вы любите маркированные списки, так что вот вам статья со списком, который состоит из нескольких сотен элементов.
Читать дальше →
Total votes 37: ↑34 and ↓3 +31
Comments 58

Невероятные приключения Роберта Хэнбери Брауна и Ричарда Твисса. Часть 2: под Южным крестом

Reading time 7 min
Views 13K
В прошлый раз я рассказал, как при помощи радиотелескопа засечь Спутник-1 и ракету-носитель, и почему этого недостаточно для астрономии. А сегодня наши главные герои придумают, как сделать телескопы на порядки мощнее, отправятся искать чистого неба и познакомятся с тонкостями астрономии в Австралии. Добро пожаловать под кат.


Читать дальше →
Total votes 20: ↑19 and ↓1 +18
Comments 10

Как я делал веб-версию KeePass

Reading time 6 min
Views 80K
Как-то мне надо было добавить в админку просмотр списка паролей. База хранилась на сервере в формате KeePass (kdbx v2), сервер был на ноде — недолго думая, я взял первый попавшийся пакет и сделал. А потом понадобилось то же самое, но прямо у пользователя в браузере, без сервера. Ничего не нашлось. Первым желанием было форкнуть либу и заменить использование node api, но от первого просмотра кода желание пропало, решил сделать сам.



Под катом расскажу о проблемах, с которыми я столкнулся, и способах их решения
Читать дальше →
Total votes 134: ↑133 and ↓1 +132
Comments 162

Оптимизация AngularJS: рабочие примеры

Reading time 3 min
Views 23K
Многие статьи об оптимизации производительности, в первую очередь пытаются «заглянуть под капот» Angular и перегружают читателя информацией о внутренней организации фреймворка. Знакомство с внутренними механизмами работы очень важно, но в данной статье я попытался собрать самые простые примеры, которые оказывают наибольшее влияние на производительность приложения и помогают максимально быстро решить типичные проблемы.
Читать дальше →
Total votes 24: ↑17 and ↓7 +10
Comments 31

Юнит-тестирование для чайников

Reading time 15 min
Views 1M
Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?

We need to go deeper
Total votes 70: ↑63 and ↓7 +56
Comments 65

Пишем maintainable код

Reading time 8 min
Views 47K
У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.

Читать дальше →
Total votes 58: ↑52 and ↓6 +46
Comments 202

AngularJS + UI Router: проверка авторизации и прав доступа

Reading time 3 min
Views 74K
Если ваше приложение предполагает авторизацию пользователей и/или проверку прав доступа, то вам придется либо изобретать велосипед, либо гуглить в поисках подходящего решения. В принципе, я тоже это делал. В итоге я принял приемлемым для себя описанный ниже вариант.

Предпосылки


Информацию об авторизованном пользователе я решил хранить в sessionStorage, копируя её при запуске приложения в $rootScope. Также по рекомендации авторов UI Router я храню в $rootScope значения объекты $state и $stateParam, для удобного доступа. Информацию же о доступе к тому или иному состоянию можно передавать через блок data при описании самого состояния. Поскольку в моем приложении везде закрыт доступ, я решил идти от обратного и добавлять значение noLogin = true для состояний, которые не требуют авторизации, например страницы ввода логина, восстановления пароля или регистрации.
Читать дальше →
Total votes 31: ↑27 and ↓4 +23
Comments 23

7 правил создания красивых интерфейсов

Reading time 8 min
Views 180K


Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление


Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:
  • разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
  • UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

Читать дальше →
Total votes 86: ↑81 and ↓5 +76
Comments 34

Учебник AngularJS: Всеобъемлющее руководство, часть 1

Reading time 7 min
Views 272K

Содержание


1 Введение в AngularJS
2 Engineering concepts in JavaScript frameworks
3 Modules
4 Understanding $scope
5 Controllers
6 Services and Factories
7 Templating with the Angular core
8 Directives (Core)
9 Directives (Custom)
10 Filters (Core)
11 Filters (Custom)
12 Dynamic routing with $routeProvider
13 Form Validation
14 Server communication with $http and $resource

1 Введение в AngularJS


Angular – MVW-фреймворк для разработки качественных клиентских веб-приложений на JavaScript. Он создан и поддерживается в Google и предлагает взглянуть на будущее веба, на то, какие новые возможности и стандарты он готовит для нас.

MVW означает Model-View-Whatever (модель – вид – что угодно), то есть гибкость в выборе шаблонов проектирования при разработке приложений. Мы можем выбрать модели MVC (Model-View-Controller) или MVVM (Model-View-ViewModel).

Этот обучающий материал задумывался как отправная точка для изучения AngularJS, его концепций и API, чтобы помочь вам создавать великолепные веб-приложения современным способом.
Читать дальше →
Total votes 44: ↑38 and ↓6 +32
Comments 29

Выразительный JavaScript: Введение

Reading time 9 min
Views 466K


Перевод книги Marijn Haverbeke "Eloquent JavaScript". Лицензия Creative
Commons attribution-noncommercial license
. Код предоставляется под лицензией MIT.


Содержание



Читать дальше →
Total votes 54: ↑49 and ↓5 +44
Comments 14

Как Яндекс строил дата-центр с нуля

Reading time 10 min
Views 96K
Этой весной мы получили разрешение на эксплуатацию нашего нового дата-центра. Первого, для которого всё, даже здание, команда Яндекса спроектировала и построила с нуля. За те 18 лет, которые люди ищут в интернете Яндексом, мы прошли большой путь от сервера под столом одного из наших разработчиков до постройки дата-центра, где используем оборудование собственной разработки. По дороге у нас появилось несколько дата-центров в России, в которые мы перестроили прекратившие когда-то свою работу заводы и цеха.



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

В этом посте мы хотим рассказать, как мы проектировали ДЦ, с какими сложностями столкнулась наша команда в процессе строительства, как проходила пуско-наладка, в чем особенности дата-центров Яндекса и как устроена рекуперация тепла, о которой вы уже могли слышать.
Читать дальше →
Total votes 108: ↑104 and ↓4 +100
Comments 72

DICOM Viewer изнутри. Функциональные возможности

Reading time 9 min
Views 66K
Добрый день, хабрасообщество. Мне хотелось бы продолжить рассмотрение аспектов реализации DICOM Viewer'а, и сегодня речь пойдёт о функциональных возможностях.


Итак, поехали.
Читать дальше →
Total votes 30: ↑29 and ↓1 +28
Comments 22

Документация Mojolicious: Потерянные Главы

Reading time 10 min
Views 7K
Это продолжение серии статей о веб-фреймворке для Perl — Mojolicious: первая часть.

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

Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay


Mojo::IOLoop::Delay предоставляет механизм, обеспечивающий для асинхронно выполняющихся callback-ов:

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

Используемые термины:

  • (асинхронная) операция — обычно это вызов асинхронной функции вроде  таймера или выкачивания url, которой необходимо передать callback
  • шаг — callback, который анализирует данные полученные с предыдущего  шага (если это не первый шаг), и запускает одну или несколько новых  операций, либо возвращает финальный результат (если это последний шаг)
  • задача — список шагов, которые должны выполняться последовательно  (т.е. следующий шаг вызывается только после того, как все операции  запущенные на предыдущем шаге завершаются)

Альтернатива Promises

Это альтернативный подход к проблеме, обычно решаемой с помощью Promise/Deferred или Future. Вот приблизительное сравнение со спецификацией Promises/A+
Читать дальше →
Total votes 20: ↑19 and ↓1 +18
Comments 20

Документация Mojolicious: Потерянные Главы

Reading time 16 min
Views 15K
Update: статья обновлена для соответствия Mojolicious 6.0.

Mojolicious — восхитительный современный веб-фреймворк для Perl. Из недостатков я могу назвать только два: политика в отношении обратной совместимости и документация.

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

Содержание


  1. Недостатки
  2. Роутинг: внутреннее устройство
  3. Роутинг: настройка
  4. Параметры HTTP-запроса
  5. Парсинг
  6. Tips & Tricks
    1. Поддержка неблокирующих приложений в режиме CGI
    2. Как работает Mojo::UserAgent при тестировании своего приложения
    3. ojo и Mojolicious::Lite
    4. Переменные окружения


Другие статьи в этой серии



Недостатки


В официальном FAQ написано: "… we will always deprecate a feature before removing or changing it in incompatible ways between major releases … as long as you are not using anything marked experimental, untested or undocumented, you can always count on backwards compatibility …". Для начала, вторая фраза противоречит первой. Далее, вот цитата из Guides::Contributing «Features may only be changed in a major release or after being deprecated for at least 3 months.». Честно говоря, 3 месяца это и так смешной срок когда речь идёт об обратной совместимости, но похоже что даже этот срок соблюдается не всегда (поддержку «X-Forwarded-HTTPS» сделали deprecated два месяца назад, а удалили месяц назад — да, это был «major release» поэтому формально правила не нарушены, но общее отношение к обратной совместимости вполне показательно). Как много разработчиков обновляет фреймворк чаще чем раз в 3 месяца, да ещё и при этом тщательно вычитывает Changes или логи своего приложения на предмет deprecated-предупреждений? При этом, в течении последнего года было deprecated примерно 20 функций/фич. На практике, конечно, всё не так плохо, как это звучит — что-то ломается не так уж часто (лично меня за последний год коснулась только замена $app->secret() на $app->secrets()). Но факт остаётся фактом — обратную совместимость ломают, ломают часто, причём без по-настоящему веских причин: например, в случае с secret() абсолютно ничего не мешало добавить в код
sub secret { shift->secrets([shift]) }
либо просто добавить поддержку дополнительных параметров в secret() вместо добавления новой функции secrets() реализовав нужную фичу вообще не ломая совместимость.

Что касается документации, то многие считают её отличной, даже одним из серьёзных достоинств Mojolicious, но никак не недостатком. Проблема с документацией в том, что она вся сосредоточена на примерах. Это реально круто, когда ты начинаешь изучать фреймворк. Это экономит кучу времени, когда тебе нужно сделать фичу и ты быстро гуглишь пример аналогичной фичи в официальных guides. Но как только ты выходишь за рамки стандартных задач и возникает необходимость понять, как что-то устроено идеологически или архитектурно, какие конкретно параметры может принимать эта функция и что конкретно она может возвращать в разных ситуациях — выясняется, что для многих модулей Mojolicious такая документация отсутствует в принципе. И не потому, что эта информация относится к «недокументированным возможностям» — почти всё это мельком упоминается здесь и там в разных примерах, а значит считается «документированным». Нередко есть несколько способов получить доступ к определённым данным (параметры запроса, тело ответа, etc.) но не описано чем они друг от друга отличаются и в каких ситуациях правильнее пользоваться какими способами. И последнее — алфавитный порядок функций в доке, серьёзно?! Нет, я понимаю, все люди разные и кому-то наверняка это удобно, но многим всё-таки на порядок проще воспринимать документацию в которой функции сгруппированы по задачам. (Хотя в коде, особенно при чтении его через браузер, где не так удобно пользоваться поиском как в Vim, алфавитный порядок функций неожиданно оказался довольно удобным — кроме new/DESTROY/AUTOLOAD — их всё-таки лучше размещать в начале.) В результате, чтобы разобраться приходится вычитывать код (некоторые предпочитают вместо этого смотреть тесты!), что не так просто — во-первых он не является эталоном читабельности: автор любит использовать фишки перла, которые позволяют писать код компактно (и нередко такой код быстрее работает), но читабельность это ухудшает; во-вторых активное использование и наследования и обмена событиями между объектами усложняет понимание того, что и как происходит внутри 104 классов, из которых состоит Mojolicious-5.

С проблемой обратной совместимости мы мало что можем сделать (хотя, наверное, можно сделать плагин к Mojolicious, который будет её эмулировать по мере возможности). Зато вторую проблему решить не сложно — недостающую документацию можно написать самостоятельно. По мере изучения Mojolicious я планирую описывать некоторые вещи, которые, по-хорошему, должны быть в официальной документации, отсюда и название этой статьи.
Читать дальше →
Total votes 26: ↑23 and ↓3 +20
Comments 7

Лишние элементы или как мы балансируем между серверами

Reading time 8 min
Views 40K
Привет, Хабр! Какое-то время назад люди осознали, что увеличивать мощность сервера в соответствии с ростом нагрузки просто невозможно. Тогда-то мы и узнали слово «кластер». Но как бы красиво это слово не звучало, всё равно приходится технически объединять разрозненные серверы в единое целое – тот самый кластер. По городам и весям мы добрались до наших узлов в моём предыдущем опусе. А сегодня мой рассказ пойдёт о том, как делят нагрузку между членами кластера системные интеграторы, и как это сделали мы.



Внутри публикации вас также ждёт бонус в виде трёх сертификатов на месячную подписку ivi+.
Читать дальше →
Total votes 35: ↑31 and ↓4 +27
Comments 89

Information

Rating
Does not participate
Registered
Activity