Всем привет!
Совсем недавно Waves Labs анонсировал конкурс для разработчиков приуроченный к релизу в тестовую сеть расширения языка смарт-контрактов RIDE для децентрализованных приложений Ride4Dapps!
Мы выбрали кейс DAO, так как Ventuary планирует заниматься разработкой dApp с социальными функциями: голосованием, фандрейзингом, доверительным управлением и пр.
Мы начали работу с простого примера в Q&A-сессии и в RIDE IDE — примере с общим кошельком.
Хотелось бы рассказать один интересный механизм работы с конфигурацией распределённой системы. Конфигурация представлена напрямую в компилируемом языке (Scala) с использованием безопасных типов. В этом посте разобран пример такой конфигурации и рассмотрены различные аспекты внедрения компилируемой конфигурации в общий процесс разработки.
(english)
final String str = "abc"; //Javaval str = "abc" // Scala
Привет, Хабр! Предлагаю вашему вниманию перевод статьи "A tale on Semirings" автора Luka Jacobowitz.
Когда-нибудь задумывались, почему сумма типов называется суммой типов. Или, может, вы всегда хотели узнать, почему оператор <*> записывается именно так? И что это имеет общего с полукольцами? Заинтересовавшихся прошу под кат!
На днях мы решили пообщаться c Дмитрием Бугайченко (dmitrybugaychenko), одним из наших преподавателей программы "Анализ данных на Scala", и обсудить с ним актуальные вопросы использования Scala в задачах Data Science и Data Engineering. Дмитрий является инженером-аналитиком в "Одноклассниках".
Существуют различные способы обработки ошибок в языках программирования:
Исключения используются очень широко, с другой стороны о них часто говорят, что они медленные. Но и противники функционального подхода часто апеллируют к производительности.
Последнее время я работаю со Scala, где в равной мере я могу использовать как исключения так и различные типы данных для обработки ошибок, поэтому интересно какой из подходов будет удобнее и быстрее.
Сразу отбросим использование кодов и флагов, так как этот подход не принят в JVM языках и по моему мнению слишком подвержен ошибкам (прошу прощения за каламбур). Поэтому будем сравнивать исключения и разные виды АТД. Кроме того АТД можно рассматривать как использование кодов ошибок в функциональном стиле.
UPDATE: к сравнению добавлены исключения без стек-трейсов
Если вы не знаете, чем отличаются
someMap.map{ case (k, v) => k -> foo(v)}и
someMap.mapValues(foo)кроме синтаксиса или сомневаетесь/не знаете, к каким плохим последствиям это отличие может привести и причем тут identity, то это статья для вас.
В противном случае — поучаствуйте в опросе, расположенном в конце статьи.
Разработка программ высокого качества подразумевает, что программа и её части подвергаются тестированию. Классическое модульное (unit) тестирование подразумевает разбиение большой программы на маленькие блоки, удобные для тестов. Либо, если разработка тестов происходит параллельно с разработкой кода или тесты разрабатываются до программы (TDD — test driven development), то программа изначально разрабатыватся небольшими блоками, подходящими под требования тестов.
Одной из разновидностей модульного тестирования можно считать propery-based testing (такой подход реализован, например, в библиотеках QuickCheck, ScalaCheck). Этот подход основан на нахождении универсальных свойств, которые должны быть справедливы для любых входных данных. Например, сериализация с последующей десериализацией должна давать такой же объект. Или, повторная сортировка не должна менять порядок элементов в списке. Для проверки таких универсальных свойств в вышеупомянутых библиотеках поддерживается механизм генерации случайных входных данных. Особенно хорошо такой подход работает для программ, основанных на математических законах, которые служат универсальными свойствами, справедливыми для широкого класса программ. Есть даже библиотека готовых математических свойств — discipline — позволяющая проверить выполнение этих свойств в новых программах (хороший пример повторного использования тестов).
Иногда оказывается, что необходимо протестировать сложную программу, не имея возможности разобрать её на независимо проверяемые части. В таком случае тестируемая программа представляет собой черный белый ящик (белый — потому что мы имеем возможность изучать внутреннее устройство программы).
Под катом описаны несколько подходов к тестированию сложных программ с одним входом с разной степенью сложности (вовлеченности) и разной степенью покрытия.
В настоящее время многие компании предоставляют сервис облачного хранилища, но каждая имеет свой проприетарный клиент и их функционал, как правило, оставляет желать лучшего.
Существующие альтернативы мне не подошли в силу многих причин, поэтому я решил сделать собственный универсальный клиент — shadowcloud
Как-то так он выглядит:
С развитием микроэлектроники, rtl дизайны становились все больше и больше. Реюзабилити кода на verilog доставляет массу неудобств, даже с использованием generate, макросов и фишек system verilog. Chisel же, дает возможность применить всю мощь объектного и функционального программирования к разработке rtl, что является достаточно долгожданным шагом, который может наполнить свежим воздухом легкие разработчиков ASIC и FPGA.
В этой статье будет дан краткий обзор основного функционала и рассмотрены некоторые юзкейсы использования, также поговорим о недостатках этого языка. В дальнейшем, если тема будет интересна, продолжим статью в более детальных туториалах.