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

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

В последнее время по роду деятельности мне довелось поработать с несколькими проектами связанными с криптовалютой и blockchain-технологиями. Познакомившись ближе с Ethereum и его идеологией децентрализованных приложений (ĐApp) я просто заболел этой идеей: никакой цензуры, никто не может прикрыть ваш бизнес, никто не может конфисковать ваши средства, невозможно просто взять и выключить сервер на котором работает ваше приложение. В определенный момент я пришёл к выводу, что именно в такой среде мой проект может иметь шансы на жизнь.

Итак, взглянем на фронт работ.

Хорошо размахнувшись, инженер производил мощный удар кулаком сверху монитора. Раздавался треск и… монитор оживал! Тогда, 30 лет назад, когда в свои десять лет я посещал вечерние занятия школы юных программистов в университете, только инженер имел право так чинить мониторы. Только он знал, в какое место и с какой силой приложить компьютерную технику, чтобы она ожила и мы, дети, которым повезло попасть в школу программистов, продолжили, счастливые, писать свои строчки кода.

В процессе разработки игры в текстовом режиме, мне пришлось нарисовать больше сотни анимационных ASCII спрайтов. После релиза игра получила неожиданно хорошие отзывы и было принято решение делать продолжение. Рисуя спрайты для первой части и перепробовав с десяток вариантов выбора цвета и несколько десятков различных палитр, я понял, что нужен свой, «идеальный» набор цветов на все времена. За сотни и сотни часов рисования, сложились следующие критерии идеальности палитры:

• Краткость: небольшое количество цветов в палитре. Весь набор цветов можно охватить одним взглядом.
• Полнота: цвета палитры должны равномерно и достаточно плотно заполнять цветовое пространство.
• Дискретность: цвета палитры должны отличаться друг от друга на глаз.
• Группировка: цвета должны быть удобно сгруппированы для быстрого нахождения нужного.

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

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

Если добавить строку к чему-то, то он допустит, что мы хотим получить текст, поэтому сконвертирует все в строку.

Если мы добавляем префикс "плюс" или "минус", то он допустит, что нам нужно числовое представление и сконвертирует строку в число, если сможет.

Если мы отрицаем что-то, то он сконвертирует это в булево значение.

Мы можем использовать эти особенности языка и создать немного магии со всего-лишь шестью символами: [,],(,),! и +. Если вы читаете это на десктопе, то можете открыть консоль в вашем браузере (developer tools, например) и запускать код. Просто копируйте любой код из примеров ниже в консоль, и он должен исполнится и вернуть true.

Давайте начнем с простого. Вот главные правила:

1. Префикс ! конвертирует в Boolean
2. Префикс + конвертирует в Number
3. Добавление [] конвертирует String

Вот они в действии:

![] === false
+[] === 0
[]+[] === ""

В свое время на Хабре был опубликован цикл статей «Логика мышления». С тех пор прошло два года. За это время удалось сильно продвинуться вперед в понимании того, как работает мозг и получить интересные результаты моделирования. В новом цикле «Логика сознания» я опишу текущее состоянии наших исследований, ну а попутно попытаюсь рассказать о теориях и моделях интересных для тех, кто хочет разобраться в биологии естественного мозга и понять принципы построения искусственного интеллекта.

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

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

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

Этот пост просто шутка и не пытается выставить инструменты, упомянутые здесь, в дурном свете. Я использую их постоянно, они великолепны, и я рекомендую их использовать. По мотивам It's the future @ CircleCI Blog

— Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.

— Да, я как раз занимаюсь фронтендом, юзаю пару тулз.

— Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?

— Не-не-не. Это олдскул. Джиквери мёртв — никто не использует его теперь! Тебе нужен React. Это будущее.

— Окей, лады. А что это?

Мысли Криса Койера

Одна из мыслей, которая поселилась в моей голове: должен ли frontend-разработчик быть в курсе всего? В общем смысле, frontend-разработчик может использоваться и на других рабочих местах. Вся команда разработчиков заканчивает разговор на frontend-разработчике. В этом смысл моей идеи. Frontend-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с frontend-разработчиком. Возможно, именно поэтому это такая забавная работа! Поскольку frontend-разработчик занимает центральное место в цепочке разработки, и при этом мы имеем дело с большим количеством разных специалистов, мы должны понимать их работу и иногда подсказывать, что и как сделать лучше.

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

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

Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

В этом уроке мы будем изучать React Native – фреймворк от компании Facebook для создания нативных приложений под iOS и Android. У него много общего с другим очень популярным фреймворком от Facebook – React Javascript, который предназначен для построения декларативных пользовательских интерфейсов.

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

Какой человек не любит халявы? Практически все ее просто обожают, и я не исключение. Вдохновленный статьей «Взломать Wi-Fi за 10 часов» я достал из недр харда BT5, скачанный ранее, и записал его на болванку. Результат не заставил себя ждать, и первый пароль был получен на следующее утро. И понеслась…

Почему?

Сейчас Relap.io генерирует 40 миллиардов рекомендаций в месяц на 2000 медиаплощадках Рунета. Почти любая рекомендательная система, рано или поздно, приходит к необходимости брать в расчет содержимое рекомендуемого контента, и довольно быстро упирается в необходимость как-то его классифицировать: найти какие-то кластеры или хотя бы понизить размерность для описания интересов пользователей, привлечения рекламодателей или еще для каких-то темных или не очень целей.

Задача звучит довольно очевидно и существует немало хорошо зарекомендовавших себя алгоритмов и их реализаций: Латентное размещение Дирихле (LDA), Вероятностный латентно-семантический анализ (pLSA), явный семантический анализ (ESA), список можно продолжить. Однако, мы решили попробовать придумать что-нибудь более простое, но вместе с тем, жизнеспособное.

Пытаясь разобраться с библиотекой от Facebook ReactJS и продвигаемой той же компанией архитектурой «Flux», наткнулся на просторах интернета на две занимательные статьи: «ReactJS For Stupid People» и «Flux For Stupid People». Чуть раньше я поделился с хабравчанами переводом первой статьи, настала очередь второй. Итак, поехали.

Flux для глупых людей

TL;DR Мне, как глупому человеку, как раз не хватало этой статьи, когда я пытался разобраться с Flux. Это было не просто: хорошей документации нет и многие ее части перемещаются.

Это продолжение статьи «ReactJS For Stupid People».

Перевод статьи «5 Practical Examples For Learning The React Framework», Martin Angelov

Вы вероятно слышали о популярном JavaScript фреймворке от Facebook – React. Он используется на многих популярных веб-сайтах, в том числе в Facebook и Instagram. В этой статье вы увидите 5 практических примеров, построенных при помощи React, которые помогут вам начать работать с этим фреймворком.

В рамках чтения мной книги “MongoDB: The Definitive Guide” Kristina Chodorow and Michael Dirolf, решил выписывать основные моменты из глав, для лучшего освоения материала. Возможно, кому-то это тоже будет полезно.

Insert

Insert — базовый метод для добавление информации в MongoDB. Для того, чтоб добавить документ в коллекцию делаем вот так:

> db.foo.insert( { “bar” : “baz” } );

В таких ситуациях, когда нужно добавить несколько документов, для более быстрой вставки желательно использовать, так называемые, batch insert’ы (групповая вставка)

> db.foo.insert( { “arr” : [ { a : 1 , b : 1 } , { a : 2 , b : 2 } ] } );

Грубо говоря, просто вставляем массив.

Книга «Хакеры и Художники», глава 10.

Эта глава есть только в книге, на сайте Пола Грэма она отсутствует.
Кстати, осталось совсем чуть-чуть и будет готова последняя глава книги, тем самым будет полный русский хабраперевод «Хакеров и художников». (Предыдущий перевод — Пол Грэм: «The Other Road Ahead».)

За помощь с переводом спасибо Щекотовой Яне.

Языки программирования «в разрезе»

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

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

Сегодня мы хотим поговорить о сокровенном — у нас есть API.

Мы писали, а затем переписывали его заново на протяжении четырех лет. И за это время прошли почти все классические стадии “принятия неизбежного”. Кроме одной — четвертой. И хотим поделиться нажитыми непосильным трудом выводами, что делать и не делать, если вы решите делать свой “мощный эпиай”.



Процесс создания API uCoz иногда напоминал сюжет сериала The Knick («Больница Никербокер») — с неудачными операциями, кишками и экспериментами на живых людях.

Стадия первая – Отрицание

Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое.

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

var opened = false;

Вроде, работает. Но, если быстро кликать по кнопке, меню начинает моргать, открываясь и закрываясь не успев доанимироваться в конечное состояние. Вася добавляет флаг animating. Теперь код у нас такой:

var opened = false;
var animating = false;

function onClick(event) {
  if (animating) return;
  if (opened) close();
  else open();
}

Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:

if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }

Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния... О них дальше и пойдет речь.

Знакомьтесь, это Вася.

В День космонавтики, кроме праздничного настроения, в социальных сетях начинается нытьё. Даже если отбросить маргиналов, публикующих треш, и хорошие, умные люди иногда начинают ныть. Кто-то выдумывает канонизацию Гагарина в будущем и начинает расстраиваться уже сегодня. Кто-то оплакивает отечественную космическую программу, что особенно удобно делать на фоне свежих успехов Маска. Кому-то без марсианской базы День космонавтики — не праздник. Увы, не факт, что человек высадится на Марс в этом веке, и мечты, действительно, расходятся с реальностью. В то же время, я уверен, антикосмизм (идея, что человечеству не надо идти в космос, на Земле задачи важнее) обречен, а все существующие проблемы мы когда-нибудь преодолеем. Просто потому, что космос — это замечательно. Попробую развить и аргументировать эту мысль.

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