Декораторы — это невероятно круто. Они позволяют описывать мета информацию прямо в объявлении класса, группируя все в одном месте и избегая дублирования. Ужасно удобно. Однажды попробовав, вы уже никогда не согласитесь писать по-старому.

Однако, несмотря на всю полезность, декораторы в TypeScript (заявлены также на стандарт) не так просты, как хотелось бы. Работа с ними требует навыков джедая, так как необходимо разбираться в объектной модели JavaScript (ну, вы поняли, о чем я), API несколько запутанный и, к тому же, еще не стабильный. В этой статье я немного расскажу об устройстве декораторов и покажу несколько конкретных приемов, как поставить эту темную силу на благо front-end разработки.

Помимо TypeScript, декораторы доступны в Babel. В этой статье рассматривается только реализация в TypeScript.

1 Почему JavaScript отстой
• 1.1 Плохая конструкция
• 1.2 Система типов
• 1.3 Плохие функции
• 1.4 Отсутствующие функции
• 1.5 DOM
2 Почему Lua отстой
3 Почему PHP отстой
• 3.1 Исправлено в поддерживаемых в настоящее время версиях
4 Почему Perl 5 отстой
5 Почему Python отстой
• 5.1 Исправлено в Python 3
6 Почему Ruby отстой
7 Почему Flex/ActionScript отстой
8 Почему скриптовые языки отстой
9 Почему C отстой
10 Почему C++ отстой
11 Почему .NET отстой
12 Почему C# отстой
13 Почему VB.NET отстой
15 Почему Objective-C отстой
16 Почему Java отстой
• 16.1 Синтаксис
• 16.2 Исправлено в Java 7 (2011)
• 16.3 Модель
• 16.4 Библиотека
• 16.5 Обсуждение
17 Почему Backbase отстой
18 Почему XML отстой
19 Почему отстой XSLT/XPath
20 Почему CSS отстой
• 20.1 Исправлено в CSS3
21 Почему Scala отстой
22 Почему Haskell отстой
23 Почему Closure отстой
24 Почему Go отстой
• 24.1 Базовые средства программирования (базовый язык)
• 24.2 Взаимосовместимость
• 24.3 Стандартная библиотека
• 24.4 Набор инструментальных средств
• 24.5 Сообщество
25 Почему Rust отстой
• 25.1 Безопасность
• 25.2 Синтаксис
• 25.3 Конструкция API и система типов
• 25.4 Сообщество
• 25.5 Набор инструментальных средств

Почему JavaScript отстой

Учтите, что некоторые положения относятся не к самому JavaScript, а к программным интерфейсам веб-приложений (https://developer.mozilla.org/en/docs/Web/API).

Плохая конструкция

• Каждый скрипт исполняется в едином глобальном пространстве имён, доступ в которое возможен в браузерах с оконным объектом.
• Camel-регистр никуда не годится:

XMLHttpRequest
HTMLHRElement

Введение

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

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

Всем привет, с вами Максим Иванов и Дмитрий Сергиенков, и сегодня мы решили, что мы не будем говорить о модных и полезных штуках типа ReactJS, Angular, TypeScript и других. Сегодня мы уделим внимание математике в JavaScript. Если вам нравится математика, вы можете заниматься ей всё свободное время, но если вашей целью являются не научные изыскания, а работа программистом, математика вряд ли станет лучшим объектом для изучения.

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

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

Ого! Как много информации.

Перевод руководства Samuele Zaza. Текст оригинальной статьи можно найти здесь.

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

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

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

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

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

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

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

Работая с Android часто можно видеть, как весь функциональный код помещается в методы жизненного цикла activity/fragment. В общем-то такой подход имеет некоторое обоснование — «методы жизненного цикла» всего лишь хэндлеры, обрабатывающие этапы создания компонента системой и специально предназначенные для наполнения их кодом. Добавив сюда то, что каркас UI описывается через xml файлы, мы уже получаем базовое разделение логики и интерфейса. Однако из-за не совсем «изящной» структуры жизненного цикла, его зависимости от множества флагов запуска, и различной (хоть и похожей) структуры для разных компонентов, эффективно воспользоваться подобным разделением не всегда бывает возможно, что в итоге выливается в написании всего кода в onCreate().

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

Отзывчивость, простота, гибкость и расширяемость кода — принципы, которые можно закрепить за реактивным UI.

Наверняка, если совместить реактивные backend и UI, то можно получить качественный продукт. Именно его мы и попытались сделать, разрабатывая 2GIS Dialer — звонилки, которая работает через API и при этом должна оставаться быстрой и удобной.

“Это унылое диалоговое окно действительно нужно?”

В этой статье я изложил главные принципы Material Design и дал советы по их воплощению. Текст написан по следам мастер-класса для разработчиков, который мы, Роботы, устраивали совместно с российским офисом Google (Think Mobile).


Когда-то все продукты Google выглядели по-разному плохо. Даже один продукт на разных платформах выглядел неконсистентно.

Все стало меняться в 2011 году, когда в Google начали усиленно работать над унификацией визуальной части экосистемы своих продуктов и назвали все это Project Kennedy.

Большие видео на заднем плане веб-сайтов — довольно популярный тренд в веб-дизайне. Умело примененные видео могут сделать веб-сайт более драматичным и привлекательным для пользователей.

Кроме того видео-фоны могут воспроизводиться плавно и без «тормозов» в отличие от фонов, созданны с помощью JavaScript, которые требуют загрузить определенный код и изображения прежде чем пользователь увидит результат анимации.

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

Хотя и наиболее популярным способом создания видео-фона является использование HTML5 видео тега вместе с некоторыми параметрами CSS, стоит также обратить внимание на альтернативные источники видео, например, YouTube. В этом случае, вам не придется переживать о медленном ответе сервера, потому что запрос будет отправляться напрямик в YouTube.

В этой статье, я покажу вам, как можно построить клевый сайт, использующий видео с YouTube в качестве фона. Мы будем использовать jQuery.mb.YTPlayer.js для редактирования и управления внешним видом нашего видео. Итак, приступим!

Скачать исходники
Демо

Две недели назад закончилась Школа Автоматизации Процессов Разработки (ШАПР) в санкт-петербургском Яндексе.
Забегая вперёд, скажу, что преподавателям удалось главное: за неполных три месяца они «испортили» наше восприятие процесса разработки, как и обещали в начале Школы. Ручное тестирование и сборка начали жутко раздражать, вызывая мысли вроде «а ведь сейчас, вместо выполнения рутинных операций, я бы мог писать красивый код ...».

Подробнее о том, как им это удалось, можно прочитать здесь и ещё немного здесь.

В практической части обучения мы реализовали web-блог, на базе перечисленных по ссылке выше технологий.
Меня, как android-разработчика, заинтересовала возможность применения этих технологий и инструментов для организации Continuous Integration для Android.
Вдохновлённый докладом Алексея Коровянского на MBLTDev, и, особенно, результатами Google Test Automation Conference 2014 касательно тестирования Android-приложений, я реализовал упрощенный аналог нашего учебного проекта под другую платформу, перенеся туда всё что смог и успел. На этом предисловие заканчивается и начинается собственно описание автоматизации.

Скорее всего, если вы зашли на Хабр и читаете эту статью, то хоть раз в жизни да слышали про MOOC-курсы.

Но если все же не слышали, то MOOC (по-русски принято произносить «мук») означает «Massive Open Online Course» — массовый открытый онлайн-курс. Это настоящий феномен в образовании XXI века. Газета «New York Times» назвала даже 2012 год «годом MOOC» в связи с появлением на рынке дистанционного образования 3-х «китов» — Coursera, Udacity и EdX. MOOC-ам посвящено множество статей, кто-то видит в них будущее образования, кто-то, наоборот, угрозу. Пытаются также предсказать «традиционную» и «дистанционную» составляющии обучения будущего.




Однако в этой статье я не буду обсуждать перспективы развития дистанционного образования, а расскажу про свой опыт знакомства с курсами на платформе Coursera. Эти курсы будут полезны студентам, изучающим прикладную математику и информатику, в особенности анализ данных. Многое из того, что мне дали эти курсы, как я потом понял — это знания, которыми должен обладать любой уважающий себя исследователь данных (так я предпочитаю переводить профессию Data Scientist).

7 января на Coursera начинается трек курсов по специальности «Mobile Cloud Computing with Android». В текущем году аналогичный трек состоял из 3-х курсов — было интересно и полезно. В 2015 году их аж 6 (плюс дипломный проект) — судя по программам, изменений и дополнений много.

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

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

В общем, рекомендую!

Ссылка на трек: www.coursera.org/specialization/mobilecloudcomputing2/36

В этой статье для начинающих android-разработчиков я постараюсь рассказать о том, что такое «утечки памяти» в android, почему о них стоит думать на современных устройствах, выделяющих по 192МБ на приложение, как быстро найти и устранить эти утечки в малознакомом приложении и на что нужно обращать особое внимание при разработке любого приложения.


Конечная цель этой статьи — ответ на простой вопрос:
Куда нажать, чтобы узнать, какую строчку в приложении поправить?

Новая видеозапись одного из докладов с нашей конференции мобильных разработчиков #MBLTDev. На этот раз мы решили выложить видео для Android-разработчиков и тестировщиков «Автоматическое тестирование Android приложений c любовью» от Алексея Коровянского.

Алексей является Android-разработчиком и основателем некоммерческого сообщества разработчиков Google Developer Group Омск.


Презентация

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

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

В предыдущих частях (1, 2) мы говорили о том. что рождается в головах людей при этом орг.изменении, как строить разговоры с теми, кого эта ситуация затрагивает и о 9 универсальных рецептах, которые позволяют легче пройти этот непростой период.

Сегодня поговорим о встречах с заказчиком, коллегами-менеджерами и том, для чего нужны встречи 1:1.

Как ранее сообщалось на GeekTimes, EFF при поддержке Mozilla, Cisco, Akamai, IdenTrust и исследователей из Мичиганского университета (University of Michigan) создали новый некоммерческий центр сертификации (Certificate Authority) Let's Encrypt [1]. Целью проекта является ускорение перехода всемирной паутины от HTTP к HTTPS.

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

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

Доброго времени суток уважаемые хабравчане. Как-то мне пришлось писать небольшой проект, так как у меня была возможность свободного выбора технологий я решил использовать Spring Framework. Сразу же хочу сказать я не являюсь гуру в данном фреймворке, и буду благодарен правкам.

Немного поискав на хабре, я не смог найти именно того о чем хочу вам сейчас рассказать и продемонстрировать. Поэтому решил написать пост на данную тему. Речь пойдет о JavaConfig, а именно о том как сконфигурировать Spring MVC проект не используя *.xml конфигурации, например: (mvc-dispatcher-servlet.xml).