От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями.

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

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

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


Сцена в Minecraft до и после применения нескольких шейдеров.

Цель этой инструкции

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

Данная статья участвует в конкурсе от Wunsh.ru — русскоязычное сообщество Elixir. Практики и просто сочувствующие — присоединяйтесь!

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

Distillery

Distillery предназначен для автоматизации генерации релизов Elixir проектов! Является наследником Exrm от того же автора. Очень прост в использовании.

Первым делом необходимо добавить distillery в зависимости проекта. А после выполнить mix deps.get.

Живу и тружусь в основном в Иркутске: в двух организациях, которые сложно назвать классическими. Одна относительно крупная: на примерно, т.к. есть приходящие фрилансеры, 20 человек оборот составляет несколько десятков миллионов рублей в месяц, а вторая — хобби, которое с двумя товарищами «по цеху» пытаемся монетизировать.

На Хабре есть статьи, посвящённые так называемым бирюзовым (по поводу цвета идут споры: кто-то развивает идею до изумрудных, кто-то останавливается на жёлтых, но всё это частности, и статья не об этом) организациям. Их же называют: синергетическими, холакратическими (не стоит путать с охлократическими). Есть и посты предостерегающие. И всё же…

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

Кто смотрел сериал «Доктор Хаус», тот вспомнит, что гениальный хромой врач советовал не верить ни одному слову пациентов.

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

Примеры и выводы будут как свои собственные, так и заимствованные.

Предлагаю читателям "Хабрахабра" перевод публикации "Painless Merge Conflict Resolution in Git"
из блога blog.wuwon.id.au.

В моей повседневной работе, часто приходится иметь дело со множеством git ветвей (branch). Это могут быть ветви промежуточных релизов, ветви с устаревшим API находящиеся на поддержке для некоторых клиентов, или ветви с экспериментальными свойствами. Лёгкость создания ветвей в модели Git так и соблазняет разработчиков создавать все больше и больше ветвей, и как правило бремя от большого количества ветвей становится очень ощутимым, когда приходится все эти ветви поддерживать и периодически делать слияния (merge) с другими ветвями.

У вас нет ни гроша? Питаетесь Дошираком? Отчаянно пытаетесь заработать пару баксов своим инди-детищем? Все мы были в точке невозврата в разработке, когда хотели получить какой-нибудь доход от игр, но не знали в какую сторону двигаться. На самом деле, иногда мы даже не представляли всех возможностей…

Это мой доклад с Meetup-а Московской Atlassian User Group от 1 марта 2017 года

Контекст и задача

Компания самостоятельно разрабатывает программное обеспечение (Продукты) под нужды своих бизнес-подразделений (Заказчиков). Некоторые из продуктов поставлены заказчикам и компания занимается их доработкой-развитием.

Есть общий перечень задач по каждому из продуктов (Product Backlog). Каждый месяц выходят новые релизы по некоторым продуктам.

Цель – ответить на вопрос по каким продуктам необходимо выпустить релизы и какие клиентские запросы войдут в каждый из релизов.

Результат – план разработки на следующий производственный цикл (Sprint Backlog). Список релизов по продуктам, которые будут выпущены в следующем цикле.

Бизнес-логика

Каждый из продуктов закреплен за Менеджером по продукту (Product Owner). Каждое бизнес-подразделение закреплено за IT-Business Partner-ом (Менеджер по клиенту). Менеджер по клиенту обращается к Менеджеру по продукту с возможным заказом на разработку (User Story). Если Менеджеру по продукту «боль Заказчика» и «запрошенная таблетка» понятны, то он запрашивает у Руководителя команды разработки (Team Lead-а) оценку возможности реализации опции в продукте и приблизительную трудоемкость. По результатам оценки Заказчик либо подтверждает размещение заказа либо отказывается. Так формируется список запросов на доработку продуктов (Product Backlog).

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

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

Дело в том, что примерно через месяц в Y Combinator будет проходить очередной тур отбора компаний S2017. Это самый известный и раскрученный акселератор Кремниевой долины. Участие само по себе имеет смысл, даже если вы не думаете о себе, как о стартапе. Это также возможность съездить командой в Сан-Франциско на халяву.
В этой статье — наш опыт от прошлого конкурса W2016 и расшифровка аудиозаписи с очного отбора.



Все началось случайно. Подал заявку вечером в пятницу, на неделю позже сроков объявленных на сайте. Заявка простая, заполняется за пару часов, самое сложное для нас было записать ролик на 1 минуту с объяснением того, что мы делаем. Получилось так криво, что партнер попросил удалить ссылку из статьи. Но этого оказалось достаточно, чтобы пройти конкурс 500 из 10 000 заявок и быть приглашенным на очный тур.

После отправки заявки было еще собеседование по скайпу, очень короткое, 5-10 мин. Нас спросили что мы делаем, а после ответа сказали: “Но ведь этого и так полно и никому не нужна еще одна такая система!” На это мы 5 минут наперебой рассказывали, что нет, мы делаем все по другому и у нас будет лучше всех. Нам сказали: “Ок” и через 5 дней пришло приглашение: “Прилетайте”, а еще через день мы вылетели.

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

В данном цикле статей, автор предлагает свое видение архитектурных процессов в рамках Scrum, которые вытачивались им на нескольких проектах (мобильные банки), в том числе на текущем (CleanEngine). Область применения подхода: business critical, mission critical и life critical проекты.

Участие в стартапе по эмоциям напоминает езду по американским горкам, когда в какой-то момент вы чувствуете, что владеете миром, а через секунду — что всё рушится. Это руководство может помочь в запуске стартапа.

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

В течение 6 лет я работал исключительно в стартапах. Я был «программистом» — специалистом, которого нанимали для преобразования идей в «реальный» бизнес. У меня никогда не было желания запустить моё собственное дело: стоит ли рисковать комфортной жизнью ради идеи, которая может не сработать?

Затем 4 года назад я взялся за трудное дело, основав стартап — 5-дневные курсы обучения программированию в Лондоне под названием Steer. Через два года я оставил Steer, запустив SuperHi.

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

Инвижн позволяет дизайнеру продемонстрировать заказчику прототип дизайна приложения, сделав его интерактивным. Кроме того, благодаря Инвижн, можно организовать слаженную работу внутри команды, между дизайнером, менеджером проекта, верстальщиком и программистами, независимо от платформы (macOs, Windows, Linux). Предлагаю вашему вниманию удобные сценарии использования связки Sketch + InVision.

Всем привет. Я достаточно давно пользуюсь редактором Vim для редактирования очень разных текстов: правки конфигов, написания кода, в качестве внешнего редактора в браузере и почтовом клиенте…

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

Создание программного обеспечения для стартапов — серьёзная задача. Не потому, что само написание программного обеспечения является довольно трудным, а потому, что у большинства стартапов места для выполнения такой работы далеки от оптимальных. За свои более чем 10 лет опыта разработчика ПО для стартапов я научился не доверять способности работодателей обеспечить мне адекватную рабочую среду, и это мешает мне выполнять работу для них наилучшим образом. Я, по своей природе, амбициозный, энергичный, и я не хочу ничего более, чем выдать на том месте, где я работаю, лучшее из того, что я могу. Я отдаю себя на 100% компании, в которой я работаю. Но в большинстве мест, где я работал, было сделано немало, чтобы воспрепятствовать мне в этом. Вот почему в какой-то момент времени я занял чёткую позицию: отныне я буду работать только «удалённо».

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

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

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

Известный маркетолог Эндрю Чен в одном из эссе писал, что есть всего несколько каналов для масштабирования роста аудитории:

• Платный трафик
• Прямые продажи
• Виральность
• SEO

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

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

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


“У всех есть свои раннеры, а чем мы хуже? Мы тоже сможем запилить за месяц крайне простую игру для телефонов”, — подумали мы немногим больше года назад, и все завертелось.

Мы нарисовали пару скетчей, написали диздок на 2 листа и взяли Unity, с которым у нас уже был небольшой опыт работы. Решив, что справимся с простым раннером примерно за месяц-два, приступили к работе.

Осторожно, под катом довольно много картинок!

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

Ниже я постараюсь объяснить вам самые базовые вещи — эллиптические кривые, ECC, приватные / публичные ключи и так далее. По возможности я буду иллюстрировать свои слова примерами кода, преимущественно на Python 2.7, если что-то непонятно — спрашивайте в комментариях.