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

В примерах используется JavaScript ES2015). (Почему JavaScript?)

Работа над материалом продолжается; присылайте свои пулл-реквесты в оригинальный репозиторий на английском языке.

В документе используются термины из спецификации Fantasy Land spec по мере необходимости.

Arity (арность)

Количество аргументов функции. От слов унарный, бинарный, тернарный (unary, binary, ternary) и так далее. Это необычное слово, потому что состоит из двух суффиксов: "-ary" и "-ity.". Сложение, к примеру, принимает два аргумента, поэтому это бинарная функция, или функция, у которой арность равна двум. Иногда используют термин "диадный" (dyadic), если предпочитают греческие корни вместо латинских. Функция, которая принимает произвольное количество аргументов называется, соответственно, вариативной (variadic). Но бинарная функция может принимать два и только два аргумента, без учета каррирования или частичного применения.

Введение

Эта история началась практически сразу после написания статьи об исследовании аркады небезызвестной корейской компании: в аркадном автомате Tank! Tank! Tank! от Namco вышел из строя жесткий диск (что неудивительно, т.к. производитель установил в автомат не отличающиеся надежностью Seagate 7200.12), диск взяли с рабочей аркады и скопировали его через WinHex, после чего игра перестала запускаться. Предположив, что целостность диска была нарушена неосторожным нажатием клавиши в окне редактирования данных на диске в WinHex, был взят другой диск с еще одного рабочего автомата, скопирован аналогичным образом, который также перестал запускаться. Тут-то и стало понятно, что в диск каким-то образом встроена защита от копирования.

На пути к рекапитализации:
ПОЧЕМУ РЫНОК, ФИНАНСИРУЮЩИЙ «ЕДИНОРОГОВ», СТАЛ ПРОСТО ОПАСНЫМ… ДЛЯ ВСЕХ ВОВЛЕЧЁННЫХ В НЕГО.

21 апреля 2016 г.

В феврале прошлого года авторы журнала «Fortune» Эрин Гриффит и Дэн Примакк провозгласили 2015 год «эрой единорогов», указав, что "«Fortune» насчитывает более 80 стартапов, каждый из которых оценивается венчурными инвесторами более чем в 1 млрд. долларов". К январю 2016 года их количество взлетело до 229. Одной из определяющих причин такого роста популяции «единорогов» стала замечательная лёгкость мобилизации капитала для создания такого зверя: заявите новую оценку стоимости компании намного выше последней, придумайте представительный заголовок, потребуйте предложений — и наблюдайте поток из сотен миллионов долларов на ваш банковский счёт. Через двенадцать-восемнадцать месяцев вы «отчаливаете» и делаете такое снова — потрясающе просто!

Хотя на поверхности не видно, но в инвестиционном сообществе произошла фундаментальная трансформация, которая сделала возрастающие инвестиции в «единорогов» существенно более опасной и сложной практикой. Все участники «единорогов» — учредители, сотрудники компании, венчурные инвесторы и их компаньоны-вкладчики (LP) — видят свои состояния под угрозой, происходящей от самой природы явления «единорога». Давление, создаваемое чрезвычайно высокими бумажными оценками стоимости, значительной скоростью сгорания (и последующей потребностью в большем количестве денег) и беспрецедентными низкими уровнями IPO и M&A, создало сложную и уникальную ситуацию, в которой многие определяющие руководители (гендиректоры) «единорогов» и инвесторы плохо ориентируются.

Многие отмечают, что совокупная биржевая стоимость акций, создаваемая всеми такими стартапами, значительно превышает потери от их неизбежно разоряющихся собратьев. Эта, вроде бы, банальность основывается на ясном успехе качественно новых компаний этого поколения (AirBNB, Slack, Snapchat, Uber и т.д.). В то время как сиё обстоятельство могло бы дать некоторое ощущение комфорта, большинство этих стартапов не представлено в корзине «единорогов», и нет какого-либо признака, что их можно купить. До некоторой степени большинство участников такой экономической системы может воздействовать на специфическую эффективность компании и несёт за это ответственность, что точно объясняет, почему важно понимать изменяющийся пейзаж.

Разрабатываем мы тут некоторый сервис интеграции с очень сторонней системой. Сам сервис работает на Node.js. И всё бы хорошо, но только недоступность сервера во время сборки мусора очень нервировала стороннюю систему.

В канун нового года было решено сделать серверу подарок — обновить Node.js с версии 0.4.8 до 0.6.6 В силу ряда организационных причин, обсуждать которые здесь не очень хочется, обновление было проведено сразу на боевой системе и даже без регрессионного тестирования.

Неужели в этой ситуации что-то могло пойти не так?

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



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

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



Продолжение: Создание простого Chrome приложения

Под конец прошлого года компания Amazon выпустила (наконец-то!) C++ SDK для своей платформы AWS. Непонятно, почему так долго тянули — есть масса приложений, написанных на С++, из которых давно хотелось удобно пользоваться AWS. Не джавой же единой, в самом деле.

Всегда интересно посмотреть на что-то, написанное на С++ в наши дни с нуля, без груза обратной совместимости и странных архитектурных решений, присущих некоторым разработкам прошлого. Я не буду тут пересказывать документацию, но остановлюсь на ключевых моментах, определяющих всё поведение SDK.

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

Похоже на то, что пользователям нужно не так и много. Дело в том, что на днях приложение «Yo», отсылающее соответствующий возглас/сообщение своим контактам, вошло в топ-10 самых популярных приложений в App Store (США). Плюс ко всему, нашелся инвестор, вложивший в это приложение 1 миллион долларов США.

Всего через два месяца после версии 2.6 вышел Git 2.7 с новыми возможностями, исправлениями и улучшениями производительности. Что интересного он нам приготовил? Я расскажу о нескольких новинках, которые показались интересными команде Bitbucket.

Полноценный набор команд git worktree

Команда git worktree появилась в Git 2.5, она позволяет выгружать и одновременно работать со многими ветками репозитория в отдельных папках. Например, если нужно сделать срочную правку, но при этом не хочется трогать текущую рабочую копию, можно просто выгрузить нужную ветку в новую папку с помощью команды:

$ git worktree add -b hotfix/BB-1234 ../hotfix/BB-1234
Preparing ../hotfix/BB-1234 (identifier BB-1234)
HEAD is now at 886e0ba Merged in bedwards/BB-13430-api-merge-pr (pull request #7822)

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Если вы из тех, кто «работал ещё Там-То!» и «делал ещё То-То!», а сейчас счастливо отдыхаете на пенсии — эта статья не для вас. Просто спасибо за труд и примите мои поздравления. Но если же вы, как и я, даже став немного старше всё ещё ощущаете страсть к программированию, радуетесь виду кода и не можете устоять перед желанием написать ещё что-нибудь, тогда продолжайте читать.

Большую часть моей жизни я проработал разработчиком программного обеспечения. Но однажды, уже под конец моего четвёртого десятка, я попался на удочку предпринимательской наживы. Я тогда поверил, что создавать собственные компании — это круто. Я нашел немного венчурного капитала и организовал пару небольших стартапов для реализации собственных идей. И вот я стал, как мне казалось, нормальным CEO и не таким уж плохим менеджером. И, хотя я уже не писал код лично, я мог нанимать хороших программистов, управлять качеством проектов и внедрением инноваций.

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

В продолжение предыдущего топика "Как на самом деле работает мозг". На написание данного поста меня побудила, с одной стороны, замечательная книга «Grooming, Gossip, and the Evolution of Language» Робина Данбара (Robin Dunbar), а с другой — очередная порция «полезных» и «умных» советов в GTD и других блогах.

Для затравки — небольшая логическая задачка. Дан набор карточек; на каждой из них на одной стороне написана буква, на другой — цифра.
На столе лежат четыре карточки: «А», «Д», «5» и «6». Вам говорят: если на карточке (из числа лежащих на столе) на одной стороне гласная, то на обороте — чётная цифра. Какие из карточек достаточно перевернуть, чтобы однозначно подтвердить или опровергнуть это утверждение?

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

А ваше приложение — RESTful? Чтобы ответить на этот вопрос нужно сначала разобраться что такое RESTful. Бытует мнение, что отдавать правильные коды ответов в HTTP — это уже RESTful. Или делать правильные идемпотентные HTTP-запросы — это вообще очень RESTful. Мы в Хекслете сделали практический курс по протоколу HTTP (отличия версий, отправка форм, аутентификация, куки и пр.), и в нем мы стараемся рассказать о правильном использовании запросов, но нужно понимать, что RESTful это не про HTTP, это вообще не про протоколы интернета. Современный веб и взаимодействие между браузером и сервером с помощью HTTP и URI могут удовлетворять принципам RESTful, а могут и не удовлетворять.

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

Итак, Вы собираетесь создать новый [] функциональный, [] императивный, [] объектно-ориентированный, [] процедурный, [] стековый, [] мультипарадигменный, [] быстрый, [] статически-типизированный, [] динамически-типизированный, [] чистый, [] богатый, [] не-искусственный, [] наглядный, [] простой для новичков, [] простой даже для не-программистов, [] абсолютно непостижимый язык программирования.

Не получится. И вот почему.

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

В данном посте речь пойдет о моем участии в конкурсе Ludum Dare 34, который был около трех недель назад.

В результате получился пазл под названием Growing Sakura, геймплей которой можно видеть на гифке (не пугайтесь, она весит всего 300Кб):


Кратко о правилах игры: изначально у нас есть гексагональное поле и несколько корневых бутонов (или один, как на гифке выше). Из него можно пустить 3 ветки (двумя способами — кликая левой или правой кнопкой мыши). Из каждого бутона на ветке левым кликом мыши можно сделать Y-разветвление, а правым — просто продолжить ветку дальше (I-разветвление). Если в каком либо направлении ветка расти не может (соответствующая клетка занята или в нужном направлении нет клетки) — то ветка не растет. В соответствии с последним условием нужно правильно выбирать порядкок «разворачивания» веток. В итоге получится дерево (или несколько деревьев) такое, что между двумя смежными ветками нет острых углов. Цель игры — покрыть все клетки игрового поля.

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

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

Однако, в зависимости от вида, каждые 7, 11, 13 или 17 лет периодические цикады одновременно массово вылезают на свет и превращаются в шумных летающих тварей, спариваются и вскоре умирают.

Хотя наши странные цикады весело уходят в иной мир, возникает очевидный вопрос: это просто случайность, или числа 7, 11, 13 и 17 какие-то особенные?

Сей пост навеян неожиданным для меня интересом хабранаселения к посту уважаемого Milfgard из Мосигры про производство в Китае. Дело в том, что один из моих интересов как раз в производстве батарей – Denaq. И производство расположено ну конечно же в Китае. Я не стану рассказывать про организацию производства, там свои замечательные фокусы есть. Я расскажу именно про заказ чего-то под себя и покупку всякого опта. Что-то вроде алгоритма украшенного реальными историями из личного опыта. Это все будет про электронику, так как я сам именно ею занимаюсь. Истории и иллюстрации я буду выделять курсивом. Кому скучно читать общие выводы – читайте только их.

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

Мотивация

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

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

Во всяком случае, это только первый черновик стандарта, который я предлагаю. Комментарии приветствуются!

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Предисловие

Не знаю, все ли программисты всесторонне любознательные люди, но я всегда пытаюсь получить фундаментальные знания во всех областях, которые могут быть практически полезны. В то время, когда мне в голову пришла эта идея я изучал анатомию и физиологию по журналам «Тело человека. Снаружи и внутри», ну а по работе я занимался стерео-варио фотографиями (для тех кто не знает — были такие советские календарики с ребристой поверхностью, где картинка либо казалась объемной, либо менялась). Так вот, в один из вечеров мне пришла в голову замечательная идея, которую я на протяжении уже 4х лет использую для поддержания своего зрения.
Обещаю, что эффект почувствуете сразу!