1. Dripicons V2



Удивительный набор из 200 аккуратных иконок для разных потребностей, которые доступны в форматах SVG, Webfont, PSD и Sketch.

«Next generation web framework for node.js» — так написано в документации к версии 1.0. Звучит неплохо, я к этому добавлю что 2 года назад после внедрения koa на одном из проектов у наших программистов появился термин “псевдо-синхронный код” (Это когда код выглядит как синхронный но на самом деле исполняется асинхронно). Что за бред Как это работает я расскажу под катом.

В 2014 году я выступил на открытии конференции GopherCon с докладом под названием «Go: Best Practices for Production Environments». В SoundCloud мы были одними из первых пользователей Go и к тому времени уже два года писали на нём и поддерживали Go в бою в той или иной форме. За это время мы кое-чему научились, и я попытался поделиться частью этого опыта.

С тех пор я продолжал программировать на Go в течение всего рабочего дня, сначала в командах SoundCloud, отвечающих за операционную деятельность и инфраструктуру, а теперь работаю в компании Weaveworks над Weave Scope и Weave Mesh. Также я усердно трудился над Go kit, набором инструментов для микросервисов с открытым исходным кодом. И всё это время я принимал активное участие в развитии сообщества Go-программистов, встречался со многими разработчиками на митапах и конференциях по всей Европе и в США, коллекционируя их истории успехов и провалов.

В ноябре 2015-го, на шестую годовщину релиза Go, я вспоминал то своё первое выступление. Какие из лучших практик прошли проверку временем? Какие из них устарели или стали неэффективными? Появились ли какие-то новые методики? В марте мне представилась возможность выступить на конференции QCon London, где я рассказал о лучших практиках 2014 года и дальнейшем развитии Go до 2016 года. В этом посте представлена выжимка из моего выступления.

Ключевые положения я выделил в тексте в виде Top Tips — лучших советов.

А вот и cодержание:

1. Среда разработки
2. Структура репозитория
3. Форматирование и стиль
4. Конфигурация
5. Разработка программы
6. Логирование и метрики
7. Тестирование
8. Управление зависимостями
9. Сборка и развёртывание
10. Заключение

12 мая мы с товарищами зашли в московское метро с его открытием утром и, не выбираясь наверх, посетили все 199 доступных в данный момент станций до закрытия метрополитена. Зачем мы всё это сделали – совершенно не ясно, но я попробую рассказать, как так получилось.

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

По мере изучения вопроса я обнаружил, что идея сама по себе не то чтобы очень нова – в нью-йоркской подземке аналогичные соревнования проходят с 1966 года. Что же касается московского метро, то ЖЖ-пользователь estrella-de-sur полгода назад проехал его за 12 часов 36 минут (расчётное время – 11 часов 50 минут) по правилу «один шаг на каждую станцию». Но у нас была другая задача – мы хотели выйти на каждой станции и по возможности красиво её сфотографировать. Это означало, что нам в большинстве случаев придётся ждать на ней следующего поезда. Исходя из этого я и строил расчёт.

Предупреждение: если вы умеете решать задачу коммивояжёра на 200 узлах (с помощью генетических алгоритмов или без них) – вас, скорее всего, ждут в другом месте. Можете просто пролистать пост и посмотреть картинки.

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

Я рассматриваю такую задачу. Есть пул заданий, которые надо побыстрее выполнить. В PHP есть и другие инструменты для решения этой задачи, тут они не упоминаются, статья именно про pthreads.

Стоит отметить, что автор расширения, Joe Watkins, в своих статьях предупреждает, что многопоточность — это всегда не просто и надо быть к этому готовым.

Кто не испугался, идем далее.

Ремарка от автора
Это статья новая, но она не о новых возможностях. Она о core, то есть о платформе и о том что многие кто просто используют grunt, или webpack могут не подозревать, так скзать about fundamentals.

Более подробно читайте:

комментарии rumkin:
habrahabr.ru/company/mailru/blog/283228/#comment_8890604

комментарии Aiditz:
habrahabr.ru/company/mailru/blog/283228/#comment_8890476

комментарии Suvitruf:
habrahabr.ru/company/mailru/blog/283228/#comment_8890430

Идея этой публикации была навеяна серией книг Кайла Симпсона «Вы не знаете JavaScript». Они являются хорошим началом для изучения основ этого языка. А Node — это практически тот же JavaScript, за исключением небольших отличий, о которых я расскажу в этой статье. Весь код, приведённый ниже, вы можете скачать из репозитория, из папки code.

Зачем вообще переживать насчёт Node? Node — это JavaScript, а JavaScript используется почти везде! Мир был бы лучше, если бы большинство разработчиков в совершенстве владели Node. Чем лучше приложения, тем лучше жизнь!

Эта статья представляет собой реалистичный взгляд на наиболее интересные основные возможности Node. Ключевые моменты статьи:

1. Цикл событий: освежаем ключевую концепцию, позволяющую реализовать неблокирующие операции ввода/вывода.
2. Глобальный объект и процесс: как получить больше информации.
3. Эмиттеры событий: интенсивное введение в событийную модель (event-based pattern)
4. Stream’ы и буферы: эффективный способ работы с данными
5. Кластеры: форкай процессы как профессионал
6. Обработка асинхронный ошибок: AsyncWrap, Domain и uncaughtException
7. Аддоны на C++: внесение своих наработок в ядро и написание собственных аддонов на С++

Ключевые слова: DPS (DamagePerSecond); Wolfram Mathematica; дискретность и непрерывность; матанализ; заработок игровой валюты в компьютерных играх; паки ArcheAge.

Введение

Всем знакомы однотипные вопросы в школьных задачах по математике про мотоциклиста выехавшего из пункта А в пункт Б, которые вызывают скуку, отвращение, или просто безразличие. Вопросы, которые вызывают, все что угодно кроме интереса к изучению математики. Очевидно что, гораздо больший интерес и больше эмоций вызывают вопросы типа:
1) «как он смог меня одолеть в игре, если у моего персонажа и здоровья больше и DPS (Damage Per Second) выше?!»
2) «как быстрее всего заработать голду (игровую валюту), чтобы сделать своего персонажа сильнее?!»
На самом деле эти игровые вопросы очень похожи на классические школьные задачи. Разница лишь в том, что есть заинтересованность в получении ответа на игровые вопросы, есть цель, ради которой хочется решить эти задачи. К сожалению, очень многие преподаватели в школах и вузах совершенно не умеют заинтересовать обучаемых в получении конкретной информации, новом методе решений математических задач, доведении их до ответа. Но раз уж игры вызывают этот самый интерес, то грех не воспользоваться заинтересованностью в игре, для пробуждения интереса к математическому анализу.
Вот две задачи, которые являются лишь переформулированными вышеупомянутыми вопросами.
1) Петя и Коля решили помочь дедушке наполнить две одинаковые пустые бочки водой из колодца. Петя таскал воду в 5-и литровом ведре и на один заход к колодцу и обратно к бочке тратил 3 минуты, а Коля в 8-и литровом и на один заход тратил 5 минут. Каждый заполнял свою бочку. Кто из мальчиков быстрее заполнит свою бочку, если а) объём бочки 60 литров? б) если объем бочки 56 литров? (начали мальчики одновременно)
2) Два купца Семён и Добрыня покупают у крестьян по 10 пудов мёда за 5 золотых и везут его на продажу в соседние города. Добрыня везёт в ближайший город и продаёт там за 8 золотых, весь путь до города и обратно у него занимает 2 дня. Семён же, желающий продавать своё мёд как можно дороже, не ленится и везёт его ещё дальше, тратя на весь путь 3 дня, и продавая мёд в другом городе за 10 золотых. Кто же из купцов заработает больше за 360 дней непрерывной работы? Как изменится ситуация, если оба купца вынудят крестьян снизить цену на мёд до 3 золотых?
Разбор этих задач, описанный ниже, поможет ответить на животрепещущие вопросы игры ArcheAge (и других) про «паки» и DPS. А также позволит задуматься над такими понятиями как «дискретность» и «непрерывность», а так же над таким, казалось бы, очевидным вопросом как «прибыль».

Давайте на время отвлечемся от очередного "языка-убийцы C++", ошеломляющих синтетических тестов производительности какой-нибудь NoSQL-ой СУБД, хайпа вокруг нового JS-фреймворка, и окунемся в мир "программирования ради программирования".

Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day'16 Russia, до которой осталось всего два месяца.

Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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

Предыдущая статья серии была посвящена теории парсинга исходников с использованием ANTLR и Roslyn. В ней было отмечено, что процесс сигнатурного анализа кода в нашем проекте PT Application Inspector разбит на следующие этапы:

1. парсинг в зависимое от языка представление (abstract syntax tree, AST);
2. преобразование AST в независимый от языка унифицированный формат (Unified AST, UAST);
3. непосредственное сопоставление с шаблонами, описанными на DSL.

Данная статья посвящена второму этапу, а именно: обработке AST с помощью стратегий Visitor и Listener, преобразованию AST в унифицированный формат, упрощению AST, а также алгоритму сопоставления древовидных структур.

Содержание

• Обход AST
  
  • Visitor и Listener
  • Различия в Visitor в ANTLR и Roslyn
  • Грамматика и Visitor в ANTLR
  • Альтернативные и элементные метки в ANTLR
• Типы узлов унифицированного AST
• Тестирование конвертеров
• Упрощение UAST
• Алгоритм сопоставления древовидных структур
• Заключение

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

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

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

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

Правила

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

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

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

Один из аспектов понятия «производительность Web» заключается в том, чтобы уменьшить наблюдаемые пользователем задержки; получить готовую к работе страницу как можно быстрее. В отношении протокола HTTP это подразумевает, что идеальный протокол связи выглядит как-то так:



Клиент шлёт минимально необходимое количество данных, чтобы описать свой запрос, а сервер отдаёт ему минимально необходимое количество данных для отображения страницы и всё это происходит за минимально возможное количество раундов связи. Лишние данные, пересылаемые на сервер или получаемые с сервера, означают увеличение времени загрузки и повышение шансов потери пакетов, перегруженность канала связи. Лишние циклы отправки\приёма данных из-за «болтливости» протокола и задержки (особенно в мобильных сетях, где 100ms — лучшее возможное время отклика) тоже ухудшают ситуацию.

Итак, если мы описали идеальный случай — соответствует ли ему протокол HTTP? И можем ли мы ещё как-нибудь улучшить его?

Метод Монте-Карло это алгоритм принятия решений, часто используемый в играх в качестве основы искусственного интеллекта. Сильное влияние он оказал на программы для игры в Го, хотя находит свое применение и в других играх, как настольных, так и обычных компьютерных (например Total War: Rome II). Так же, стоит отметить, что метод Монте-Карло используется в нашумевшей программе AlphaGo, победившей го-профессионала 9-го дана Ли Седоля в серии из 5 игр.

В данной статье хотелось бы рассказать про версию алгоритма Монте-Карло под названием Upper Confidence bound applied to Trees (UCT). Именно после публикации этого алгоритма в 2006-м году, программы для игры в Го сильно усилили свои позиции и достигли значительных успехов в игре против человека.

Именно столько прошло с момента выхода Qt Quick 2 и объявления о новой стратегии развития, направленной на поддержку мобильных платформ.

Технология взрослела, разработчики лечили детские болезни, но для полного счастья не хватало трех вещей:

• Правильного масштабирования на High DPI экранах
• Компонентов, специфичных для смартфонов
• Гибкой стилизации имеющихся компонентов

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

С отсутствием компонентов решалось тоже просто, но трудоемко: велосипедами. Надо заметить, что в последнее время появилось несколько приличных пользовательских наборов, под Android, Material, iOS. Для меня до сих пор загадка, почему Digia при всей ориентированности на мобильники выпустили первую версию контролов под настольные платформы, где и виджеты себя чувствуют неплохо.

Полтора года назад появился стандартный стиль имитирующий Android 4.x — ситуацию это не спасло. Стилизация у Qt Quick Controls 1 недостаточно гибкая, в общем опять велосипеды, благо пишутся они довольно просто, и почти все нужное уже написано в предыдущем пункте.

В общем до 5.6* была печалька, а теперь и на нашей улице праздник

*В Qt 5.6 новые контролы представлены в качестве технологического превью под именем Qt Labs Controls, полноценно запустятся в ближайшем релизе 5.7, который обещают в июне.

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

Коллбэки. Асинхронные. Неблокирующие. Давайте говорить начистоту: все эти JS-концепции заставляют вас рвать волосы на голове каждый раз, когда ваш код СНОВА не работает. Меня тоже посещали подобные чувства. Мне нужна была какая-то простая аналогия, которая помогла бы мне легче понять эту абстрактную идею. Конечно, в сети есть много хороших учебных материалов (например, этот, или этот). Но все они обычно сразу начинаются с довольно сложных вещей.

Мне нужно было что-то более близкое, понятное.

Мне нужны были миньоны.

Представляю вашему вниманию перевод статьи «Which Android HTTP library to use?».

Для чего это вообще?

Сегодня почти все приложения используют HTTP/HTTPS запросы как своеобразный транспорт для своих данных. Даже если вы напрямую не используете эти протоколы, множество SDK, которые вы, скорее всего, уже включили в свои приложения (например, метрика, статистика падений, реклама), используют HTTP/HTTPS для работы с сетью. На сегодняшний день совсем немного существует библиотек, которые разработчик мог бы свободно использовать в своем проекте. И я постараюсь рассказать об основных из них в этом посте.
У Android-разработчиков есть много причин, чтобы сделать выбор в пользу сторонних библиотек, заместо уже встроенных API, таких как HttpURLConnection или Apache Client. Например:

Асинхронность… Услышав это слово, у программистов начинают блестеть глаза, дыхание становится поверхностным, руки начинают трястись, голос — заикаться, мозг начинает рисовать многочисленные уровни абстракции… У менеджеров округляются глаза, звуки становятся нечленораздельными, руки сжимаются в кулаки, а голос переходит на обертона… Единственное, что их объединяет — это учащенный пульс. Только причины этого различны: программисты рвутся в бой, а менеджеры пытаются заглянуть в хрустальный шар и осознать риски, начинают судорожно придумывать причины увеличения сроков в разы… И уже потом, когда большая часть кода написана, программисты начинают осознавать и познавать всю горечь асинхронности, проводя бесконечные ночи в дебаггере, отчаянно пытаясь понять, что же все-таки происходит…

Именно такую картину рисует мое воспаленное воображение при слове “асинхронность”. Конечно, все это слишком эмоционально и не всегда правда. Ведь так?.. Возможны варианты. Некоторые скажут, что “при правильном подходе все будет работать хорошо”. Однако это можно сказать всегда и везде при всяком удобном и не удобном случае. Но лучше от этого не становится, баги не исправляются, а бессонница не проходит.

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

Я написал маленькую электронную книгу в которой рассматриваю вопросы как сделать код лучше. Книга ориентирована на Си/Си++ программистов, но будет интересна и разработчикам, использующих другие языки. Формат книги не подходит для моего любимого Хабра, но мне интересно получить обратную связь и обсудить мысли, изложенные в статье. Поэтому я решил разместить здесь только анонс, а с самой статьей можно познакомиться здесь. И приглашаю в комментарии для обсуждения.