Я расскажу о том, как настроить автоматический запуск модульных тестов в сервисе Travis CI для .NET Core проекта, в котором используется PostgreSQL.

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

Введение

Этот туториал я пишу прежде всего для себя, для того чтобы иметь возможность быстро на основе начального шаблона ASP.NET Core приложения создать минимальное приложение с поддержкой npm, Webpack и TypeScript (у которого будет работать отладка из Visual Studio).

Строим свой full-stack на JavaScript: Сервер

Вторая статья из серии о full-stack JS разработке.

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

Уважаемые хабравчане.

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

Вы можете пообщаться с ним лично в следующих чатах:
https://gitter.im/jdubray/sam
https://gitter.im/jdubray/sam-examples
https://gitter.im/jdubray/sam-architecture

Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

По поводу кода он оставил следующий комментарий:

I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).

Эта статья о том, как построить архитектуру web-приложения в соответствии с принципами MVC на основе React и Redux. Прежде всего, она будет интересна тем разработчикам, кто уже знаком с этими технологиями, или тем, кому предстоит использовать их в новом проекте.

React и Redux, в последнее время одни из самых популярных buzz-words в мире фронтенда. Поэтому когда мне потребовалось сделать веб-приложение, которое бы отображало данные, полученные с сервера, а также позволяло бы ими манипулировать (создавать, удалять и изменять), я решил построить его на основе связки React и Redux. Множество getting-started руководств покрывают только функционал создания компонентов, action creators и reducers. Но как только дело касается обмена с сервером, начинаются сложности — растет количество необходимых action creator, редьюсеров. Причем они очень похожи друг на друга, с миниальными отличиями. В большинстве случаев — только в типе (имени) активности. После того, как я создал третий одинаковый набор креаторов и редьюсеров, то появилось желание что-то изменить. Так родилась идея реализации redux-redents.

Это седьмая статья из цикла «Теория категорий для программистов». Предыдущие статьи уже публиковались на Хабре:

• Теория категорий для программистов: предисловие
• Категория: суть композиции
• Типы и функции
• Категории, большие и малые
• Категории Клейсли
• Произведения и копроизведения
• Простые алгебраические типы данных

Функторы

За понятием функтора стоит очень простая, но мощная идея (как бы заезжено это ни прозвучало). Просто теория категорий полна простых и мощных идей. Функтор есть отображение между категориями. Пусть даны две категории C и D, а функтор F отображает объекты из C в объекты из D — это функция над объектами. Если a — это объект из C, то будем обозначать его образ из D как F a (без скобок). Но ведь категория — это не только объекты, но еще и соединяющие их морфизмы. Функтор также отображает и морфизмы — это функция над морфизмами. Но морфизмы отображаются не как попало, а так, чтобы сохранять связи. А именно, если морфизм f из C связывает объект a с объектом b,

f :: a -> b

то образ f в D, F f, связывает образ a с образом b:

F f :: F a -> F b

(Надеемся, что такая смесь математических обозначений и синтаксиса Haskell понятна читателю. Мы не будем писать скобки, применяя функторы к объектам или морфизмам.)

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

«Мутации» машинного кода

Содержание

"Если хочешь идти быстро — иди один. Если хочешь идти далеко — идите вместе." (с)

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

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

• http://example.com
• www.example.com
• //www.example.com
• mailto:user@example.com

step⁰ → step¹

result⁰, item → result¹

function flatten() {
  return function(step) {
    return function(result, item) {
      for (var i = 0; i < item.length; i++) {
        result = step(result, item[i]);
      }
      return result;
    }
  }
}

var flattenT = flatten();

_.reduce([[1, 2], [], [3]], flattenT(append), []); // => [1, 2, 3]

1. Изменять элементы (прим. map)
2. Пропускать элементы (прим. filter)
3. Выдавать для одного элемента несколько новых (прим. flatten)

• трансдьюсеры могут улучшить производительность, т.к. позволят не создавать временные коллекции в цепочках операций map.filter.takeWhile.etc
• могут помочь переиспользовать код
• могут помочь интегрировать библиотеки между собой, например underscore/LoDash могут уметь создавать трансдьюсеры, а FRP библиотеки (RxJS/Bacon.js/Kefir.js) могут уметь их принимать
• могут упростить FRP библиотеки, т.к. можно будет выбросить кучу методов, добавив один метод для поддержки трансдьюсеров