Недавно мне попался маленький проект, где я предложил использование Angular и XSLT, на что я получил такой вопрос: «С чего бы использовать устаревшую технологию XSLT, ведь ее используют только с Java, да к тому же, только для Enterprise»?

Этот вопрос и явился причиной того, что я решил написать данную статью.

Итак, разрешите представить вашему вниманию «химеру» под названием Angular XSLT module. Ангулар разделяет business логику и view логику, но с модулем XSLT, view логику Angular можно вообще отдать XSLT.

Есть конечно пара подводных камней, это:

1) Результат не будет рендерится,
2) Angular команды не будут вызываться.

Но легким движением руки, эти проблемы решаются на раз-два!

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

Разреженный массив — это разновидность массива, в котором большинство значений принимает одинаковое значение.

На практике часто встречаются настолько огромные разреженные массивы, что нет никакого смысла занимать память одинаковыми элементами. Поэтому есть смысл разреженные массивы реализовывать так, чтобы память не расходовалась на хранение одинаковых значений.
В некоторых языках программирования разреженные массивы входят в сам язык, например в J, MATLAB. В других языках программирования есть специальные библиотеки, которые позволяют реализовать их. Для С++ — Eigen и др.

Глобалы — хорошие кандидаты для реализации разреженных массивов, потому что:

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


Надёжная поддержка — это важно

При поступлении в ШАД проверяются знания в рамках общей программы, включающей базовые разделы высшей алгебры, математического анализа, комбинаторики, теории вероятностей, а также основы программирования. Под катом подробно разобраны задачи вступительного экзамена в ШАД 2014 года. Внимание! Пост довольно объёмный, поэтому устраивайтесь поудобнее, вооружайтесь карандашом, если нужно, доставайте чай с печеньем. Убедитесь, что сделали все дела на вечер! Велика вероятность, что рассматриваемые ниже задачи поглотят ваш разум на несколько часов, а кому-то помешают вовремя лечь спать. Во всяком случае сегодняшний вечер обещает быть интересным. Добро пожаловать под кат ↓

Мы продолжаем нашу колонку по теме ASP.NET5 публикацией от Виктора Коцюбана ( Gbdrm) — Technical Leader из SoftServe. В этой статье Виктор поделится с вами подробностями нового встроенного функционала внедрений зависимостей в ASP.NET5. Предыдущие статьи из колонки всегда можно прочитать по ссылке #aspnetcolumn — Владимир Юнев

Внедрение зависимости – одна из самых популярных и используемых форм инверсии управления, важного принципа ООП, что позволяет уменьшить сцепление (coupling) – взаимозависимость, взаимосвязанность модулей.

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

В ASP.NET 5 встроена возможность внедрения зависимости. Что она позволяет и чем выделяется среди других таких подходов рассмотрим ниже. А также попробуем использовать ее на практике.

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Некоторые люди, столкнувшись с проблемой, думают: «О, а использую-ка я регулярные выражения». Теперь у них есть две проблемы.
Джейми Завински

Юан-Ма сказал: «Требуется большая сила, чтобы резать дерево поперёк структуры древесины. Требуется много кода, чтобы программировать поперёк структуры проблемы».
Мастер Юан-Ма, «Книга программирования»

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

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

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

При обсуждении той или иной интересной возможности языка C# рано или поздно заходит речь об известных представителей .NET community и одним из первых в этом списке идет Джон Скит (Jon Skeet), гуру stackoverflow.com и автор одной из самых интересных книг по языку C# — “C# in Depth”.

Чтобы рассказать о том, кто есть Джон и что он сделал для индустрии, достаточно привести о нем несколько фактов. Многие слышали факты о Чаке Норрисе, такие как «Чак Норрис досчитал до бесконечности. Дважды» или что «Чак Норрис единственный человек, который обыграл стену в теннис». Но далеко не все знают о том, что подобные факты есть и о Джоне Ските (сам факт существования которых уже о многом говорит).

Программисты часто сталкиваются с проблемами чтения математических нотаций, когда пытаются разобраться с теоретическими основами какого-либо языка программирования. Также с ними толкнулся и я в своих теоретических изысканиях. К счастью, мне очень помогла замечательная статья Джереми Сиека (Jeremy Siek), чьим переводом я хочу с вами поделиться. Надеюсь она поможет многим программистам-«не математикам».

Несмотря на обилие предложений всевозможных планшетов, ноутбуки не желают сдаваться. Некоторое время назад ASUS представила новые модели ультрабуков серии Zenbook. Сегодня мы представляем вашему вниманию обзор старшей модели, UX301LA.

20 июля вышла финальная версия Visual Studio 2015 RTM, несущая в себе, в том числе, много нового для веб-разработчиков, специализирующихся на JavaScript: улучшения в редакторе, поддержка популярных библиотек и систем управления пакетами и сборки кода, возможности ES6, а также обновление поддержки Apache Cordova и Node.js.

1. Выучить новый язык программирования

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

Среди языков программирования отличный познавательный эффект и наверстывание опыта дают: Lisp (или Scheme), Форт, PostScript или Factor (стековые языки программирования), Haskell (строго типизированный, чистый функциональный язык) либо OCaml (объектно-ориентированный язык функционального программирования), Пролог (логическое программирование), Erlang (отличные паралельные вычисления).

Эстафета из 100 языков программирования

Квайн — компьютерная программа, которая выдаёт на выходе точную копию своего исходного текста. Цепной квайн отличается от обычного тем, что на каждой последующей итерации выводится код на другом языке программирования, до тех пор, пока не выведется код оригинального квайна. В середине 2013 года японский программист Юсукэ Эндо (遠藤 侑介) разработал цепной квайн, содержащий 50 языков программирования. В конце 2014 кода он опубликовал новую версию, включающую уже 100 языков!

Исходники и информация о компиляции всех этих квайнов есть на гитхабе: quine-relay. Любопытно, что исходный код в виде картинки был написан не в ручную (что невозможно в принципе), а сгенерирован. Автор отмечает, что в течении года он опубликует книгу про обфусцированное программирование, которая будет включать в себя подробное объяснение о том, как писать квайны, ascii-art квайны, цепные квайны (подобные этой эстафете).

Андрей Глазков, Ито Хаято из Google, а также другие специалисты на Github работают над составлением спецификации Shadow DOM. Уже проделана огромная работа, однако еще много предстоит сделать. В рамках поддержки работы на этом направлении создан перевод существующей версии спецификации от 7 июля.

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

«Дорогой SlackHQ, я тебя люблю. Твой Дэн».

Вероятно, вы слышали про поразительный рост Slack. Вы, возможно, читали, что платформу для внутрикорпоративного общения (которой всего 2 года отроду), уже активно используют более 30000 команд и оценивают в 1 миллиард долларов. Но видели ли вы все эти сообщения о Slack в Twitter?

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

Как же компании удалось запустить продукт, вызвавший такой завидный резонанс, и быстро завоевать сердца пользователей? Когда основатель Slack Стюарт Баттерфилд (Stewart Butterfield) говорит про успех компании, то всегда упоминает в своей речи, что она возвела отзывы своих клиентов о продукте во главу угла.

В этом эксклюзивном интервью Баттерфилд (в прошлом один из основателей Flickr) рассказал, что стратегия выхода на рынок была успешной, быстрой и активной. Здесь он объясняет, насколько важно концентрировать свое внимание на уникальных особенностях проекта (и почему вы можете опустить остальное), и делится советами о том, как стать незаменимыми для своих клиентов.

До появления HTML5 единственное, что мы не могли контролировать и управлять (без перезагрузки контента или хаков с location.hash) — это история одного таба. С появлением HTML5 history API все изменилось — теперь мы можем гулять по истории (раньше тоже могли), добавлять элементы в историю, реагировать на переходы по истории и другие полезности. В этой статье мы рассмотрим HTML5 History API и напишем простой пример, иллюстрирующий его возможности.

Основные понятия и синтаксис

History API опирается на один DOM интерфейс — объект History. Каждый таб имеет уникальный объект History, который находится в window.history. History имеет несколько методов, событий и свойств, которыми мы можем управлять из JavaScript. Каждая страница таба(Document object) представляет собой объект коллекции History. Каждый элемент истории состоит из URL и/или объекта состояния (state object), может иметь заголовок (title), Document object, данные форм, позиция скролла и другую информацию, связанную со страницей.

Основные методы объекта History:

1. window.history.length: Количество записей в текущей сессии истории
2. window.history.state: Возвращает текущий объект истории
3. window.history.go(n): Метод, позволяющий гулять по истории. В качестве аргумента передается смещение, относительно текущей позиции. Если передан 0, то будет обновлена текущая страница. Если индекс выходит за пределы истории, то ничего не произойдет.
4. window.history.back(): Метод, идентичный вызову go(-1)
5. window.history.forward(): Метод, идентичный вызову go(1)
6. window.history.pushState(data, title [, url]): Добавляет элемент истории.
7. window.history.replaceState(data, title [, url]): Обновляет текущий элемент истории

Я бы хотел обсудить подводные камни, которые наиболее часто встречаются при работе с фичей async/await в C#, а также написать про то, как их можно обойти.

В недавно вышедшей Visual Studio 11 Beta встроена новая и главная фишка будущего C# 5 — асинхронное программирование с помощью async/await. Про нее уже написано достаточно много статей в том, числе на хабре — например, эта серия статей. Однако, я для себя так и не понял в чем суть нового синтаксиса, пока сам не попробовал его в деле. Данная статья — попытка самому структурировать и до конца разобраться с этим достаточно интересным инструментом и поделиться результатами с сообществом, рассказав про него немного иначе. Итак, поехали…

Привет, Хабр! Тема async/await в .NET Framework и C# 5.0 не нова и объезженна: все давно знают, что это, как оно работает, все знакомы с тем скромным фактом, что это очень текучая абстракция и поведение зависит от SynchronizationContext. Об этом очень много писали на хабре, ещё чаще этот вопрос размусоливался в блогах различных респектабельных персон .NET-сообщества.

Тем не менее, мне очень часто приходится сталкиваться с тем, что не только новички, но и матёрые тимлиды не совсем понимают, как правильно пользоваться этим инструментом в разработке.

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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

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