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

Загрузка приложения и менеджер состояний

До момента загрузки самого фрэймворка, его зависимостей и отработки всех запросов в бэкграунде приложение может выглядеть весьма удручающе. И даже ng-cloak не сможет помочь в большинстве случаев. Обычно для таких целей используют div имеющий больший z-index чем основной контент сайта и перекрывающий его до загрузки всех компонентов и состояний. Он может выглядеть так:

<div class="loader" ng-show="loader"><div class="loader-content">Loading...</div></div>

5 причин использовать AngularJS в вашем корпоративном приложении

Нынешнюю ситуация в мире корпоративных приложений можно описать одним словом: хаос.

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

Всем привет!

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

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

Привет, Хабр! Мы мы продолжаем делится с сообществом полезными материалами о разработке и дизайне. В этот раз команда TrackDuck подготовили перевод статьи Jeff Dickey о Angular, которая нам очень понравилась и в свое время заставила пристальней присмотреться к Gulp. Эта статья будет полезна разработчиками, которые хотят сэкономить время на рутинных операциях и построить качественные процессы при разработке веб-приложений. Мы активно используем Angular для разработки собственного продукта для визуального комментирования веб-сайтов, поэтому готовы ответить в комментариях на интересующие вас вопросы!

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

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

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

Идея заключалась в следующем: генераторы случайных чисел «прогоняются» через группу тестов NIST, чтобы понять, где возникает уязвимость, позволяющая использовать неэффективность рынка для извлечения прибыли. В ходе эксперимента автор пришел к выводу, что поведение рынка нельзя описать в терминах простого подбрасывания монетки, как считают отдельные авторитетные ученые. Некоторым тестам удалось зафиксировать определенный уровень «шума» в поведении рынка. Один из них – тест на линейную сложность – привлек внимание автора, поскольку напоминает об идее отношения случайности и степени сжатия.

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

На днях широкое внимание привлекло состоявшееся в начале года на митапе NYC Lisp выступление Джеральда Джей Сассмана, — одного из авторов великого и могучего SICP, а также крестного отца Scheme. Всему виной — ответ на вопрос, почему в MIT прекратили преподавать ставший легендарным курс 6.001, построенный на основе книги Сассмана и Абельсона «Структура и интерпретация компьютерных программ» (вопрос задан на 59 минуте).



Сассман назвал две причины; впрочем, сразу замечу, что в первой из них нет ничего особенного. К 1997 году Абельсон и Сассман уже устали рассказывать практически одно и то же с 80-ых, поэтому решили оставить преподавание и предложили главе кафедры самостоятельно решить, как поступить с самим курсом. Здесь удивляться действительно нечему — что угодно может осточертерть, если заниматься им достаточно долго.

Впрочем, вторая причина гораздо серьезнее. По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня. В 80-ых и 90-ых инженеры строили сложные системы, комбинируя простые и хорошо изученные «части». Целью SICP было предоставить язык абстракций для рассуждений о таких системах.

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

Сегодня JavaScript лежит в основе большинства современных веб-приложений. При этом за последние годы появилось большое количество JavaScript-библиотек и фреймворков для разработчиков Single Page Application (SPA), графики, анимации и даже серверных платформ. Для веб-разработки JavaScript используется повсеместно, и поэтому качество кода обретает всё большее значение.

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

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

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

Для затравки начнем с простого.

Все мы слышали про ajax и node.js. Они прочно обосновались уже не просто в словарном запасе, но и в наборе инструментов веб-разработчика. Ajax — асинхронное подтягивание данных с сервера на страницу, node — фреймворк с асинхронным IO. Но как в таком однопоточном языке, как Javascript, реализуется та самая асинхронность?

Вы, наверное, уже догадались из заголовка, речь пойдет об основном цикле («main loop»).

От переводчика: Я думаю многие читали статью Rey Bango — What to Read to Get Up to Speed in JavaScript, но до хабра обсуждение так и не докатилось. Предлагаю закрыть этот пробел и поговорить о хороших книгах, блогах, тренингах и конференциях, посвященных в первую очередь клиентскому JavaScript и клиентской веб-разработке. Чтобы не копипастить оформляю статью в виде перевода.

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

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

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

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

Объекты, классы, конструкторы

ECMAScript, будучи высоко-абстрактным объектно-ориентированным языком программирования, оперирует объектами. Существуют также и примитивы, но и они, когда требуется, также преобразуются в объекты. Объект — это коллекция свойств, имеющая также связанный с ней объект-прототип. Прототипом является либо также объект, или же значение null.

В JavaScript нет привычных классов, но есть функции-конструкторы, порождающие объекты по определенным алгоритмам (см. Оператор new).

Прототипное делегирующее наследование

Классическое наследование очень похоже на то, как люди наследуют гены своих предков. Есть какие-то базовые особенности: люди могут ходить, говорить… И есть характерные черты для для каждого человека. Люди не в состоянии изменить себя — свой класс (но могут поменять собственные свойства) и бабушки, дедушки, мамы и папы не могут динамически повлиять на гены детей и внуков. Все очень по земному.

Теперь представим другую планету, на которой не такое как на Земле генное наследование. Там обитают мутанты с «телепатическим наследованием», которые способны изменять гены своих потомков.
Разберем пример. Отец наследует гены от Дедушки, а Сын наследует гены от Отца, который наследует от Дедушки. Каждый мутант может свободно мутировать, и может менять гены своих потомков. Например у Дедушки был зеленый цвет кожи, Отец цвет унаследовал, Сын тоже унаследовал цвет. И вдруг Дед решил: «надоело мне ходить зеленым — хочу стать сними», смутировал (изменил прототип своего класса) и «телепатически» распространил эту мутацию Отцу и Сыну, вобщем посинели все. Тут Отец подумал: «Дед на старости лет совсем двинулся» и поменял свой цвет в генах обратно на зеленый(изменил прототип своего класса), и распространил «телепатически» свой цвет сыну. Отец и Сын зеленые, Дед синий. Теперь как бы дед ни старался Отец и сын цвет не поменяют, т.к сейчас Отец в своем прототипе прописал цвет, а Сын в первую очередь унаследует от Прототипа Отца. Теперь Сын решает: «Поменяю ка я свой цвет на черный, а моё потомство пусть наследует цвет от Отца» и прописал собственное свойство, которое не влияет на потомство. И так далее.

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

Привет, Хабр!

Мы в Хекслете используем JavaScript не только для очевидных задач во фронтэнде, но и, например, для реализации браузерной среды разработки (наш опен-сорсный hexlet-ide) на React'е. У нас есть практический курс по JavaScript, и один из уроков там посвящен замыканиям. Это важная тема не столько в рамках JS, сколько в программировании вообще. Мы освещаем ее и в других курсах.

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

Я использую замыкания уже достаточно давно. Я научился их использовать, но не до конца понимал как они на самом деле работают, что происходит «под капотом». Что это вообще такое? Википедия не очень помогает. Когда замыкание создается и уничтожается? Как выглядит реализация?

"use strict";
 
var myClosure = (function outerFunction() {
 
  var hidden = 1;
 
  return {
    inc: function innerFunction() {
      return hidden++;
    }
  };
 
}());
 
myClosure.inc();  // возвращает 1
myClosure.inc();  // возвращает 2
myClosure.inc();  // возвращает 3
 
// Ага, круто. А как это реализовано?
// И что происходит под капотом?

Примечание от переводчика:

Этот пост был написан и опубликован на Medium разработчиком приложений Адрианом Космачевским из Швейцарии. Кроме подготовки перевода его публикации, я также пригласил и самого автора, Адриана ( akosma ), на Хабр, для того, чтобы он смог лично ответить на любые вопросы участников сообщества, если таковые возникнут. Думаю, для общего удобства при общении в комментариях с ним стоит использовать английский (и, при желании, дублировать на русском).

---

Привет всем, я — сорокадвухлетний программист-самоучка, а это моя история.

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



Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 10 часов утра 6 октября 1997 года, в городе Оливос, к северу от Буэнос-Айреса, в Аргентине. Был понедельник. Не так давно я праздновал свой 24-й день рождения.

Мир в 1997 году

Тогда он был немного другим. На веб-сайтах не было предупреждений об использовании cookie. Новаторскими в сети были сайты вида Excite.com, а моим любимым поисковиком был AltaVista.

Мой электронный ящик имел вид kosmacze@sc2a.unige.ch и был расположен на личном веб-сайте, который размещался по адресу http://sc2a.unige.ch/~kosmacze. Тогда мы еще оплакивали принцессу Диану, а Стив Джобс только-только вернулся на роль CEO и убедил Microsoft «вбросить» в Apple Computer 150 миллионов долларов. Digital Equipment Corporation подала в суд на Dell, останки Че Гевары вернули на Кубу, только начался четвертый (!) сезон «Друзей». Был убит Джанни Версаче, скончались Мать Тереза, Рой Лихтенштейн и Жанна Кальман. Люди зависали за Final Fantasy 7 на PlayStation, будто бы были наркоманами, Би-Би-2 начал вещание телепузиков, а Кэмерон только собирался показать миру свой «Титаник».

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

Что такое LLVM?

LLVM — это по-настоящему удобный для разборки и сборки «ранний» компилятор для таких традиционных языков программирования, как C и C++.

LLVM настолько хорош, что считается «больше, чем просто компилятором» (это динамический компилятор, он работает с языками, не относящимися к семейству C, он представляет собой новый формат доставки для App Store и т. д. и т. п.). Все перечисленное верно, но для нашей статьи важно лишь приведенное выше определение.

LLVM имеет несколько ключевых отличий от других компиляторов:

• Главное новшество — промежуточное представление (ПП). LLVM работает с ПП, которое действительно можно прочитать (если вы умеете читать ассемблерный код). Возможно, кому-то это не покажется столь уж большим откровением, однако это свойство очень важно. ПП других компиляторов обычно имеют настолько сложную структуру, что их невозможно записать вручную, трудно понять и использовать.

Компания Hola объявляет начало весеннего конкурса по программированию! Призовой фонд увеличен:

1. Первое место: 3000 USD.
2. Второе место: 2000 USD.
3. Третье место: 1000 USD.
4. Возможно, мы решим отметить чьи-то чрезвычайно оригинальные решения двумя специальными призами в 400 USD.
5. Если Вы отправите кому-то ссылку на этот конкурс, поставив наш адрес в CC, и этот человек займёт призовое место, Вы получите половину суммы приза (разумеется, не в ущерб награде победителя). За одного победителя такую награду может получить только один человек — тот, кто отправил ссылку первым.

Мы ищем талантливых программистов, поэтому авторы интересных решений будут приглашены на собеседования.

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

Правила

На этот раз мы решили попробовать что-то новенькое: для разнообразия, этот конкурс — не на производительность кода.

Условия конкурса на английском языке размещены на GitHub. Ниже — перевод на русский язык.