Спустя полгода сообщество Go-разработчиков снова воссоединилось в нашем московском офисе 14 апреля. И теперь у нас есть возможность ознакомиться с тем, как проходила эта встреча. Пять докладов и прочие подробности ищите под катом.
Читать полностью »
Функциональное программирование (ФП) может улучшить ваш подход к написанию кода. Но ФП непросто освоить. Многие статьи и руководства не уделяют внимания таким подробностям, как монады (Monads), аппликативность (Applicative) и т. д., не приводят в качестве иллюстраций практические примеры, которые могли бы помочь нам в повседневном использовании мощных ФП-методик. Я решил исправить это упущение.
Хочу подчеркнуть: в статье сделан упор на том, ЗАЧЕМ нужна фича Х, а не на том, ЧТО такое фича Х.
Сегодня платформа Ethereum стала одним из самых узнаваемых брендов блокчейн сферы, вплотную приблизившись по популярности (и капитализации) к Bitcoin. Но из-за отсутствия "полноценного" рускоязычного гайда, отечественные разработчики все еще не очень понимают, что это за зверь и как с ним работать. Поэтому в данной статье я попытался максимально подробно охватить все аспекты разработки умных контрактов под Ethereum.
Я расскажу про инструменты разработки, сам ЯП, процесс добавления UI и еще много интересного. В конечном итоге мы получим обычный сайт-визитку, но "под капотом" он будет работать на умных контрактах Ethereum. Кого заинтересовало — прошу под кат.
Наверняка, вы знаете, кто такой Джон Скит: №1 на Stack Overflow, автор C# in Depth, одной из лучших книг по .NET, разработчик в Google и 14-кратный MVP. Разработчиков такого масштаба не так много, хватит двух порядков, чтобы их всех перечислить. 19-20 мая Джон приедет в Петербург и выступит на DotNext 2017 Piter.
Мне удалось пообщаться с Джоном и взять у него большое интервью по поводу судьбы .NET, .NET Core, нововведений в C# 7 и общем уровне развития среднего разработчика в 2017 году.
Если говорить конкретно, то обсудили следующие вопросы:
Интервью получилось очень большое, но мне кажется, оно стоит каждой потраченной на него минуты.
Читать полностью »
Мне нравится думать, что я пишу хороший код. Ну или, что я хотя бы пишу больше хорошего кода, чем плохого.
Моя любимая особенность хорошего кода — это его скука. Предсказуемые выражения, одно за другим. Никаких сюрпризов, никаких трюков, никаких уникальных случаев. Никакого мета-программирования, конечно! Скучный код очень легко отлаживать, читать, объяснять.
Скучный код не использует глобальных состояний, не порождает побочных эффектов и старается уменьшить свою связанность с проектом, в котором он живёт. Скучнейшим образом происходят присвоения значений, которые для каждой переменной случаются лишь раз и избавляют нас от возможности увлекательного расследования кто же и когда изменил вот это состояние. Скучный код делает лишь то, что должен и не полагается на какие-то неявно высказанные предположения.
Код, использующий неявное поведение, может быть основан на каком-нибудь недокументированном, но уже реализованном функционале. Например, в мире написана целая куча НЕВЕРНОГО кода, который полагается на то, что функция файловой системы, возвращающая список директорий, вернёт их в отсортированном по алфавиту порядке. Это и вправду часто работает именно так, но ровно до того момента, пока не ломается по «непонятным» причинам. А на самом деле просто никто никогда этой сортировки не гарантировал.
Читать полностью »
В Voximplant мы в основном занимаемся автоматикой звонков: автоматически ответить и рассказать что с заказом, автоматически позвонить перед доставкой, автоматически соединить с нужным клиентом — вся вот эта история и JavaScript в облаке. Но кроме этого мы любим делать к нашей платформе SDK: Web SDK, чтобы звонить из браузера и в браузер, нативные Android и iOS SDK, чтобы в роуминге звонить через интернет, React Native SDK, чтобы звонить из кросс-платформенных приложений. А несколько дней назад мы сделали SDK для Unity. Который позволяет звонить из виртуальной реальности.
Читать полностью »
У нас сразу две отличные новости. DevExtreme, наш набор компонентов для фронтенд-разработки, переехал на GitHub и стал доступен бесплатно для некоммерческого использования!
Наш репозиторий — это не форк и не обрезанная версия. Это новый дом для DevExtreme, и там всё по-настоящему — от исходников до систем тестирования и сборки. Каждый желающий сможет наблюдать за тем, как мы фиксим баги (куда же без них) и добавляем новый функционал, а также поучаствовать в обсуждениях.
Вести разработку на GitHub — одно удовольствие. Механизм pull-реквестов с удобным code review — то, чего нам не хватало, пока мы жили во внутреннем Mercurial-репозитории. Теперь каждое изменение видят несколько пар глаз, что обеспечивает больший уровень прозрачности и позволяет процессам разработки плавно интегрироваться в методологии, принятые в команде (© SeOd).
В первые дни репозиторий выглядит пустовато, так как при импорте кода мы схлопнули историю коммитов. Но это продлится недолго! В дополнение к традиционным релизам, которые никуда не денутся, мы будем также оформлять Releases на GitHub и там же выпускать промежуточные pre-release и hotfix версии. Подписавшись на DevExpress/DevExtreme, например, с помощью сервиса Sibbell вы всегда будете в курсе наших последних новостей. Читать полностью »
При переходе к распределённым системам с большим количеством инстансов сервисов в полный рост встают проблемы их обнаружения (service discovery) и балансировки запросов (load balancing) между ними. Как правило, для их решения используются такие специализированные инструменты как Consul, Eureka или старый добрый Zookeeper, в сочетании с Nginx, HAProxy и некоторым мостом между ними (см. registrator).
Основная проблема в подобном подходе это большое количество интеграций, и, как следствие, точек где что-то может пойти не так. Ведь помимо вышеупомянутых решений наверняка будет использоваться локальный маленький PaaS (например Mesosphere Marathon или Kubernetes). Последние, к слову, уже хранят необходимую конфигурацию об окружении (ведь через них идёт весь деплоймент). И встаёт вопрос, а можем ли мы отказаться от специализированных инструментов для service discovery и переиспользовать тот же Marathon для этой задачи?
Краткий ответ — можем. Если интересно как — читайте дальше.
От переводчика:
Я подготовил для вас адаптированный перевод с небольшими дополнениями и исправлениями. Я сохранил несколько пропагандистский стиль оригинальной статьи, но, сама по себе, информация в ней интересная, поэтому решил, все же, перевести.
Люди часто спрашивают меня:
Зачем мне вообще использовать RxJava или Reactor, если то же самое можно сделать с помощью Streams, CompletableFutures и Optionals?
Проблема, на самом деле, в том, что большую часть времени вы занимаетесь решением простых задач и вам действительно не нужны эти библиотеки. Но когда все усложняется, вам приходится писать какой-то уродский кусок кода. Затем этот кусок кода становится все более и более сложным и трудно поддерживаемым. В RxJava и Reactor есть много удобных функций, которые будут удовлетворять вашим потребностям еще долгие годы.
Давайте определим 8 критериев, которые помогут нам понять разницу между этими библиотеками и стандартными возможностями Java:
Автор материала рассказывает, как ему удалось применить навыки программирования для автоматизации рутинных процессов собственного свадебного мероприятия.
Для большинства людей 3 сентября 2016 было самой обычной субботой, но в моей памяти эта дата останется навсегда, ведь именно в этот день мы с моей супругой сыграли свадьбу.
Планируя свадьбу, вам нужно учесть множество моментов: еда, оформление и обстановка, настольные светильники (да, отдельно от оформления), цветы, размещение гостей, транспорт, развлечения и выбор места мероприятия. Вообще, планируя свадьбу, вы сталкиваетесь со множеством неизвестных, однако в одном я был уверен наверняка: ни одна свадьба не обходится без целой кучи списков, вложенных списков, не заканчивающихся до самого конца. Чем больше списков проплывали перед моими глазами, тем чаще я стал задумываться о том, как можно улучшить процесс подготовки. Уж больно неэффективно и вручную выполнялась вся работа. Я был уверен, что технологии наверняка смогут помочь улучшить хотя бы некоторые моменты.
Читать полностью »
