Привет, Хабр! Мы стараемся поддерживать разработчиков инструментами, технологиями, информацией и вниманием. Одно из направлений нашей деятельности — программа Google Developers Launchpad, система поддержки стартапов и разработчиков приложений. Она была не так давно запущена в мире и практически сразу пришла и в Россию.

В рамках этой программы мы предоставляем различные возможности: как бизнес-услуги, PR-продвижение, так и технические вещи. Например, доступ к сервису Firebase, расширенный доступ к Google Maps API, к инструментам тестирования и тому подобное. Мы также даём возможность командам один на один пообщаться с экспертами Google, которые могут оценить дизайн и инфраструктуру приложения, посоветовать, как лучше реализовывать те или иные функции или оптимизировать приложение.

Программа перспективная и ряд российских проектов уже прошел или сейчас проходит через неё. Вместе с проектом AppTractor.ru мы отобрали шесть участников Launchpad и поговорили с ними об их работе.

Доклад посвящен асинхронному программированию в PHP, где будут рассмотрены все доступные для разработчика возможности: от самых примитивных до самых высокотехнологичных, о которых вы еще, возможно, не знаете.

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

Послушайте первые два выпуска и вы узнаете про:

• SPL структуры данных (стек, очередь, массив) против классического array и что нам принесёт PHP 7
• эффективное пересечение массивов, поиск элемента или проверку вхождения в массив
• проблему с хешами паролей, даже если вы используете новые функции хеширования из PHP 5.5
• Russia Laravel Meetup и DevConf 2015
• сравнение производительности Golang, Scala, Elixir, Ruby, Python 3 и PHP в сферических попугаях в вакууме
• оптимизацию использования памяти и как написать свой сборщик мусора на PHP
• почему Doctrine ORM не подходит для PHP
• рендеринг ReactJS шаблонов на сервере с помощью PHP
• пример использования генераторов (yield)
• прошлое, настоящее и будущее Code Coverage от автора PHPUnit
• проблемы Zephir с PHP 7
• хорошие статьи о PHP 7, которые уже есть на хабре
• написание и тестирование API на PHP, Rails и Go от Phil Sturgeon
• TDD — Train Driven Development

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

Воздействие vs Абстракция

Первое, что вы должны сделать — пойти почитать пост “Abstraction or Leverage” от Майкла Найгарда. Это отличная статья.

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

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

WebFonts. История

WebFonts — это технология использования сторонних шрифтов на своей веб-странице. Один из примеров:



Если начинать с истоков, тег font был введен в 1995 году, а уже в 1996-м было написано программное определение на CSS. Начиная с версии CSS 2.0 была введена загрузка и синтез шрифта в браузерах, но тем не менее тогда еще популярный, а ныне старый и неактуальный IE не имел поддержки загрузки шрифтов, что мешало бурному развитию использования шрифтов на своем сайте.

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

В 2000 году я был большим фанатом PHP. Я начал пользоваться им сразу после официального выхода версии 4.0 в апреле. В то время кроме него было всего 4 альтернативы для создания веб-сайтов.

1) C – слишком сложный для часто меняющегося проекта. Компиляция занимала много времени, было мало свободных инструментов, а платные не влезали в мой бюджет. Слишком многословный. Управление зависимостями было сложным делом.

2) Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.

3) Perl – почти так же хорош, как PHP, только без системы управления пакетами. На CPAN был набор модулей на все случаи жизни, но их надо было скачивать и устанавливать. Управление зависимостями было сложным делом.

4) ASP – почти так же хорош, как PHP, только это был инструмент от Microsoft, и его использование засосало бы меня в их дорогой мир.

Для трёх позиций я написал: " Управление зависимостями было сложным делом". Для меня это был ключевой момент PHP. Его философия была «всё в одном». Таких, как сейчас, систем управления пакетами тогда не было. Сейчас есть удобные штуки типа Bundler для Ruby и Leiningen для Clojure. Но не в 2000-м. Даже системы управления пакетами в Linux стали лучше с 2000 года. А система «всё в одном» решала проблемы управления пакетами в PHP. Но теперь это преимущество не имеет значения.

Уважаемые читатели! Представляю вашему вниманию перевод методологии создания веб-приложений The Twelve-Factor App от разработчиков платформы Heroku. Мои комментарии скрыты спойлерами по ходу статьи.

Введение

В наши дни программное обеспечение обычно распространяется в виде сервисов, называемых веб-приложения (web apps) или software-as-a-service (SaaS). Приложение двенадцати факторов — это методология для создания SaaS-приложений, которые:

• Используют декларативный формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключенных к проекту;
• Имеют соглашение с операционной системой, предполагающее максимальную переносимость между средами выполнения;
• Подходят для развертывания на современных облачных платформах, устраняя необходимость в серверах и системном администрировании;
• Сводят к минимуму расхождения между средой разработки и средой выполнения, что позволяет использовать непрерывное развертывание (continuous deployment) для максимальной гибкости;
• И могут масштабироваться без существенных изменений в инструментах, архитектуре и практике разработки.

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

Сегодня мы с гордостью представляем релиз Rust версии 1.0, нового языка программирования для создания более надёжных и эффективных систем. Раст объединяет в себе низкоуровневый контроль над производительностью с удобством и гарантиями безопасности языков высокого уровня. Лучше того, он при этом не требует сборщика мусора или среду выполнения, так что библиотеками на Расте можно безболезненно заменять библиотеки на C (англ.). Если вы хотите поэкспериментировать с Растом, лучше всего начать с раздела «Getting Started» книги Rust Book (если вы предпочитаете читать с электронных книг, Паскаль Хертлиф (Pascal Hertleif) поддерживает неофициальные версии этой книги в электронном виде).

Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Ramjet

Нереально крутой скрипт, который производит морфинг DOM элементов. Выглядит потрясающе! Работает с HTML и SVG элементами, а также с изображениями. Ramjet содержит в себе базовую коллекцию функций анимации и максимально прост в использовании:

<div id='a' style='background-color: red; font-size: 4em; padding: 1em;'>a</div>
<div id='b' style='background-color: blue; font-size: 4em; padding: 1em;'>b</div>

<script src='ramjet.js'></script>
<script>
    // to repeat, run this from the console!
    ramjet.transform( a, b );
</script>

Это вторая часть нашей минисерии статей «Чего ждать от PHP7». Читать часть 1

Как вы наверное уже знаете, PHP7 придет в этом году! И сейчас самое время узнать что же нового он нам принесет.

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

Новый экранирующий символ для Unicode

Добавление нового escape-символа \u позволяет нам указывать специфические unicode символы внутри PHP-строк (да-да, те самые emoji и не только).

Синтаксис выглядит так — \u{CODEPOINT}, например, зеленое сердце, , может быть выражено как PHP-строка: "\u{1F49A}".

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

Забейте. Функциональный код отличается одним свойством: отсутствием побочных эффектов. Он не полагается на данные вне текущей функции, и не меняет данные, находящиеся вне функции. Все остальные «свойства» можно вывести из этого.

Нефункциональная функция:

a = 0
def increment1():
    global a
    a += 1

Функциональная функция:

def increment2(a):
    return a + 1

Вместо проходов по списку используйте map и reduce

MySQL — одна из самых распространенных СУБД. Ее можно встретить повсюду, но наиболее часто она используется многочисленными сайтами. Именно поэтому безопасность базы данных — очень важный вопрос, ибо если злоумышленник получил доступ к базе, то есть большая вероятность, что он скомпрометирует не только ресурс, но и всю локальную сеть. Поэтому я решил собрать всю полезную инфу по взлому и постэксплуатации MySQL, все трюки и приемы, которые используются при проведении пентестов, чтобы ты смог проверить свою СУБД. 0day-техник тут не будет: кто-то еще раз повторит теорию, а кто-то почерпнет что-то новое. Итак, поехали!

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

Доброго времени суток всем. Это наш первый пост в блог стартапа «Meanotek», и наверное он будет больше ознакомительного характера. Чтобы не было совсем скучно читать, мы попробуем рассказать историю, о том как одна практическая задача привела нас к созданию полноценной системы «понимания» текста компьютером, и что из этого получилось.

Мысль научить компьютер общаться на человеческом языке у меня появилась еще в школе, когда у меня дома был один из первых советских аналогов IBM PC, с языком программирования GW BASIC. Понятно, что далеко эта задумка в то время не ушла, потом ее заслонили другие более важные дела, но совершенно неожиданно она всплыла вновь спустя много лет, уже в связи с конкретной потребностью.

Собственно идея пришла в голову во время работы над другим проектом — сайтом поиска отзывов reviewdot.ru. Идея reviewdot.ru была в следующем — пользователь вводит запрос, например «зеркальный фотоаппарат для начинающих» — и получает список ссылок на отзывы в интернете, которые касаются именно этого вопроса. Или к примеру, чтобы по запросу «что ломается в стиральной машине Indesit?” появлялись ссылки на отзыв пользователей марки Indesit, у которых что-то сломалось. Вопрос ценности данного ресурса для людей пока оставим за скобками, и поговорим немного о технической стороне реализации.

Рекурсия: см. рекурсия.

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

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

— Как она сложена?
— Превосходно! Только рука немного торчит из чемодана.

Именно пытаясь разместить стройную теорию алгоритма в жесткий рюкзак реальных ресурсов и приходится постоянно кроить по живому, перепаковывать, и вместо красивых и стройных определений Фибоначчи:

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

приходится городить всевозможные грязные хаки, начиная от:

  @memoized
  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

И заканчивая вообще:

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    n0 = 0
    n1 = 1
    for k in range(n):
      n0, n1 = n1, n0+n1
    return n0

Перевод поста Стивена Вольфрама (Stephen Wolfram) "Frontiers of Computational Thinking: A SXSW Report".
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.

---

На прошлой неделе я выступал на SXSW Interactive 2015 в Остине, штат Техас. Вот несколько отредактированная стенограмма моего выступления:

Содержание

Наиболее продуктивный год
Язык Wolfram Language
Язык для реального мира
Философия Wolfram Language
Программы размером в один твит
Вычислительное мышление для детей
Ввод запросов на естественном языке
Масштабная идея: Символьное программирование
Язык для развёртывания
Автоматизация программирования
Масштабные программы
Интернет вещей
Машинное обучение
Исследования Вычисляемой Вселенной
Вычислять, подобно тому, как это делает мозг
Язык как символьное представление
Пост-лингвистические понятия
Древняя история
Чем будет заниматься искусственный интеллект?
Бессмертие и за его пределами
Коробка триллиона душ
Обратно в 2015 год

API синтаксического анализатора

Продолжаю свой предыдущий пост. Время сфокусироваться на деталях внутреннего устройства синтаксического анализатора. В качестве языка реализации я выбрал Go, поскольку хотел малой ценой получить параллельный (в смысле, использующий все доступные ядра CPU) производительный инструмент, без погружения в низкоуровневую пучину C++.

Полученный код предоставляет следующий API:

type Attribute struct {
    Name   string
    Value  string
}

type ParseMatch struct {
    Text            string
    Nonterminal     string
    Rule            string
    Attributes      []Attribute
    Submatches      []ParseMatch
    Hypotheses      []string
    HypothesisCount uint
}

func Parse(text, nonterminal string, hypotheses_limit uint) []ParseMatch

Match ссылается на дочерние объекты того же типа, соотвествующие нетерминалам или лексическим терминалам подошедшего правила. В общем случае, из-за неоднозначности, присущей естественным языкам, тексту соответствует несколько разборов (например, из-за наличия омонимов). Поэтому функция Parse возвращает множество объектов Match. Вышеупомянутая неоднозначность синтаксического разбора должна устраняться на следующем (семантическом) уровне анализа текста.

Итак, функция Parse берёт text — текст для разбора, nonterminal — название нетерминала (например, «sentence»), а также максимальное число выдвигаемых гипотез hypotheses_limit (об этом чуть ниже). Параметр nonterminal может быть пустым. В этом случае тексту будет сопоставляться лексический терминал, найденный в морфологической базе.

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

Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).

В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.



Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…

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

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

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

Мы продолжаем наши еженедельные публикации учебных материалов Технопарка. Предыдущие лекции были посвящены web-технологиям в целом, а также алгоритмам и структурам данных. В третьем блоке лекций рассказывается о языках С и С++.

Лекция 1. Язык С. Основы организации и использования оперативной и сверхоперативной памяти

Лекция начинается с введения в язык С: рассказывается об истории его появления, особенностях, преимуществах и недостатках, о сферах применения. Описываются основы препроцессорной обработки, рассматриваются вопросы управления памятью (модели управления памятью, области видимости объектов хранения) и производительность программ на языке С. Обсуждается связывание объектов хранения и их инициализация. Затем рассказывается о классах памяти в языке С. Следующая часть лекции посвящена проблематике указателей, а также работе с одномерными массивами. В заключение рассматривается стандарт POSIX и вопросы переносимости.