Прочитал еще одну статью про «психологические типажи разработчиков». И с меня хватит. Как всегда, в этой статье предлагают узнать себя в одном из антипаттернов «плохих парней», понять, что я врежу бизнесу и начать наконец «исправляться». Я вот узнал себя в каждом типе. Я и рок-звезда, и солдат, и некомпетентный, и мечу в менеджеры… Короче, все выглядит так, что каким бы разработчиком и человеком я ни мечтал быть, бизнес увидит здесь проблему.

Знаете что? Пусть катятся к черту.

В процессе разработки CUBA мы применяли все три основных инструмента сборки — начали с Ant, потом перешли на Maven на короткое время, а сейчас используем Gradle и, похоже, что в ближайшее время останемся с ним.

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

Сейчас в издательстве ДМК-Пресс выходит русский перевод японской манги 2013 года про цифровые схемы, созданной Амано Хидэхару и Мэгуро Кодзи. Несмотря на несерьезную форму изложения, суть этой книжки очень здравая. Например, она начинает от древних микросхем малой степени интеграции и быстро привязывает их к современному языку описания аппаратуры Verilog и программируемым логическим интегральным схемам (ПЛИС). Также манга четко определяет зачем нужны комбинационные и последовательностные схемы, и дает представление о методах оптимизации.

Манга избегает ошибок многих своих предшественников. Одну из таких ошибок совершил Чарльз Петцольд в книге «Код», которая вводила последовательностную логику не на D-триггерах, управляемых фронтом тактового сигнала (edge-triggered D-flip-flop), а на D-триггерах с работой по уровню (защелках, level-sensitive D-latch), хотя потом переключалась на правильные триггеры. Вероятно, ошибка была связана с тем, что Чарльз Петзольд, который прославился как автор учебников по программированию GUI в Microsoft Windows, не был практикующим разработчиком электроники, и для него защелки были «проще», чем триггеры с фронтом. Проблема в том, что защелки плохо совместимы со статическим анализом задержек при логическом синтезе, главной технологии проектирования цифровых схем последних 30 лет. Системы на кристалле внутри гаджетов типа айфона в качестве элементов состояния в 99% случаях используют D-триггеры переключаемые по фронту, а защелки используют только в очень специальных случаях. Давать новичкам строить схемы на защелках — это значит вводить их в заблуждение.

В этом смысле манга лучше чем Петзольд. Вот как элегантно манга объясняет работу двухступенчатого master slave D-триггера, управляемого фронтом тактового сигнала. Это делается с помощью феи «Хи-хи-хи» и феи «Ха-ха-ха»:

UPD: так как тема хорошо зашла и показала наличие спроса на такой сервис, буду развивать его дальше. Завел паблик вконтакте для сбора фидбека и публикации информации об обновлениях https://vk.com/sightsafari

Незнакомый район города, небольшое количество свободного времени и необходимость (или желание) пешком добраться до метро/отеля/вокзала – наверное, каждый хоть раз попадал в такую ситуацию. При этом с одной стороны хочется посмотреть какие-нибудь красивые и интересные места, однако с другой стороны ограниченное время не позволяет слишком сильно уклоняться от прямого маршрута.

Ситуация еще больше осложняется, если рядом нет никаких крупных достопримечательностей, о которых все знают и которые можно было бы включить в свой маршрут после короткого поиска в интернете. Что делать если вы застряли в каком-нибудь Купчино, про которое вы только и слышали, что там лучше не застревать? Приходится идти по навигатору, надеясь, что на пути встретится что-то интересное. Однако популярные навигаторы учитывают лишь расстояние и время в пути, но не принимают во внимание интересность маршрута. Мне попадались еще проекты, пытающиеся учитывать удобство пешего маршрута (ведущие в обход шумных магистралей), но хочется же пройти не только комфортно, но и увидеть какие-нибудь красоты.



Подумав немного, я решил взяться за эту задачу сам. Как всегда, общая идея алгоритма довольно проста, но дьявол кроется в мелочах. А в случае навигации, мелочи могут быть довольно существенны и с риском для здоровья, ведь вряд ли какой-нибудь турист обрадуется, когда навигатор в поисках достопримечательностей заведет его в дебри полузаброшенной промзоны ради маленькой мемориальной таблички (тру стори, один раз так и случилось).

Описание алгоритма и примеры работы под катом, ссылка в конце.

В последние несколько лет мои переживания по поводу российского рынка ИТ только усиливались. Все началось с кризиса рубля 2014 года (а может, и раньше), и с тех пор меня не покидает ощущение, что многие российские компании, особенно провинциальные, завязали себе глаза, заткнули ватой уши и все еще пытаются сделать вид, что ничего не происходит. Я много общался с разными компаниями, с HR, с разработчиками, и составил список неутешительных тезисов о том, что представляет собой как программистский рынок, так и культура разработки в целом, ведь это вещи взаимосвязанные. По моим субъективным оценкам, эти тезисы справедливы для ~60% российских компаний, хотя, казалось бы, те другие 40% компаний, которые мы знаем и любим, должны были заставить задуматься. Но я очень подозреваю, что это эти 60% просто надеются на русский “авось”, и подвергаются так называемой willful blindness, а иногда и намеренно мутят воду. Итак, по-честному, что же происходит?

Дисклеймер 1. Ни ссылок, ни имен, ни пруфов не будет. Как известно, в Интернете можно найти подтверждение или опровержение любому тезису, поэтому не вижу большого в том смысла, покуда это не диссертация, а мнение. Моя цель — предоставить другую точку зрения, основанную на личностном опыте веры на личном опыте.

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

Сказать, что для Docker'а 2017 год выдался тяжёлым, было бы преуменьшением. Не могу вспомнить ни одного столь раскрученного и хорошо обеспеченного деньгами стартапа из Долины, кроме Uber'а, который бы провёл 2017 год так же невнятно, как Docker. 2017 стал тем годом, когда Docker, великолепный образчик программного обеспечения, был полностью уничтожен плохим бизнес-управлением. Эта заметка — сторонний взгляд на то, как и где Docker пошёл не туда, и как попытки что-либо исправить оказались слишком слабыми и запоздалыми.

В этой статье я не буду описывать преимущества и недостатки механических клавиатур. Одной единственной идеальной клавиатуры для всех не существует. Многие считают вершиной развития «островные» клавиатуры с ножничным механизмом, кто-то может комфортно печатать лишь на Topre, другие запаслись парой-тройкой IBM Model M на всю оставшуюся жизнь. Вокруг переключателей Cherry MX и их клонов диапазон предпочтений тоже весьма широк — одним подавай лёгкие линейные переключатели, другим нужны жёсткие MX Green с кликом. Речь пойдёт о компактной разновидности, так называемых «шестидесятипроцентных клавиатурах».

С тех пор как я перешел к работе над крупными, комплексными проектами, я продолжаю утверждаться в том что есть два типа программистов – назовем их логики и визуалы.

• Логики – это программисты с классическим флёром. Чтобы познакомиться с новой технологией они идут и читают документацию. Четкость кода – повышенная, ни шага влево, ни шага вправо. От забора и до обеда. Непритязательность к удобству работы с кодом пугает – кажется, что они могут работать и с минифицированным кодом, пользуясь одной только функцией поиска.
• Визуалы – это люди, подходящие к коду более творчески, абстрактно. Чтобы изучить технологию они идут в youtube и смотрят видео про дельфинов уроки. В коде им важно разделение на осязаемые блоки, отсутствие простыней на 1000+ строк, возможность реализовать по-новому. Выполняя новую задачу они будут пристреливаться и искать свой вариант решения вместо поисков уже имеющегося на просторах интернета.

Речь в этой статье пойдет об инструменте разработки, без которого я, как представитель второго типа, уже не мыслю разработку проектов размером больше 250 строк и который, я уверен, будет полезен нашим коллегам из классического типа – он сделан в сотрудничестве с одним из вас – восходящей звездой мира программирования Степаном! Итак!

Вчера мы представили открытый фреймворк для разработки блокчейнов Exonum. Он позволит компаниям и правительственным организациям воплощать в жизнь безопасные блокчейн-решения.

Сегодня мы решили подготовить тематическую подборку для тех, кто хотел бы разобраться в устройстве блокчейн-технологии, но и не забыли более «продвинутых» пользователей.

Продолжение начатой в статье с подведением итогов JBreak и JPoint темы Java-конференции JPoint 2017, проводившейся 7-8 апреля 2017 года в Москве стараниями JUG.ru Group.

Ещё больше фотографий, подробностей о докладах и больше впечатлений.

Делимся продолжением истории из жизни инди-разработчиков из IzHard. Сегодня команда расскажет про события, которые с ними происходили после победы в международном конкурсе, а также про ошибки, которые они совершали в процессе развития.

(у учебника по Основам React вышло второе издание, Redux-учебник в процессе обновления)

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

Курс про Redux попал в официальную документацию.

Оба руководства бесплатны и выложены на gitbook (можно скачать PDF, ePub, mobi).

В текстах нарочно участвуют термины переведенные на русский (например, состояние), английские (state), либо английский термин написанный по-русски — стейт. Считаю это допустимым, и даже более того, удобным для читателя.

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


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

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

Открытый курс машинного обучения mlcourse.ai сообщества OpenDataScience – это сбалансированный по теории и практике курс, дающий как знания, так и навыки (необходимые, но не достаточные) машинного обучения уровня Junior Data Scientist. Нечасто встретите и подробное описание математики, стоящей за используемыми алгоритмами, и соревнования Kaggle Inclass, и примеры бизнес-применения машинного обучения в одном курсе. С 2017 по 2019 годы Юрий Кашницкий yorko и большая команда ODS проводили живые запуски курса дважды в год – с домашними заданиями, соревнованиями и общим рейтингом учаcтников (имена героев запечатлены тут). Сейчас курс в режиме самостоятельного прохождения.

Про измерение CO2 и его важность на Geektimes было уже немало публикаций (ссылки в конце статьи). Здесь же хочу описать проект компактного монитора уровня CO2, а также температуры, влажности и давления с Wi-Fi, обновлением прошивки по воздуху и интерфейсом в мобильном приложении. Сердца системы модуль на базе esp8266, сенсор CO2 MH-Z19 и фреймворк esp8266-arduino. И так, включим устройство в USB-розетку:

На этой неделе я проходила техническое собеседование в Google и, хоть и провалила, хочу поделиться опытом в этой статье.

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

Любые дискуссии на тему серверной виртуализации нередко заканчиваются на высоких тонах, переходят в бескомпромиссный спор, но начинаются они почти всегда с VMware, поэтому и мы начнем свой список вендоров лучших продуктов виртуализации для VPS именно  с этой компании.

Статья написана для тех, кто умеет писать простейшие программы на java, но не умеет их собирать. Этим людям уже известно, что такое классы, что такое пакеты и зачем нужен public static main(String[] argv), но код без среды разработки они не запускали, да и не понимают кому и зачем это вообще может понадобиться.

Сразу скажу, что Java программиста, который не может собрать свою программу из консольки, на работу не возьмут, и это в общем более чем достаточная причина, чтобы научиться искусству обращения с системами сборки. Остальное детали, которым и посвящена статья.

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

Для того, чтобы воспользоваться информацией из статьи нужно знать, что такое xml, переменные окружения, зачем нужна переменная окружения PATH и как пользоваться консолью.

Господа! Сегодня на 1 сентября, в День Знаний, группа из украинских преподавателей вузов, их аспиранток, а также российских инженеров, решили, по согласованию с британскими издателями Elsevier через компанию Imagination Technologies, сделать небольшой подарок всем учителям компьютерной архитектуры и цифровой схемотехники, особенно тем, которые используют популярный учебник Дэвида Харриса и Сары Харрис.

Просто нажмите вот на эту ссылку и вы получите zip-файл с слайдами для чтения лекций по этому учебнику на русском языке. Причем без регистрации, которая требуется для загрузки учебника как такового.

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

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

Представьте, что вам дали задачу поправить часть кода. В голове возникнет много мыслей. Кто его написал? Когда? А может он — legacy? Где документация? Давайте попробуем разобраться с «наследием» основательно и со всех сторон. Поможет нам в этом вопросе Андрей Солнцев @asolntsev (http://asolntsev.github.io/), разработчик из таллинской компании Codeborne. Начнём.

— Андрей, вы знакомы с трудами Michael Feathers, например, «Working Effectively with Legacy Code»? В книге акцентируется внимание на важности тестирования и выделяется одно из ключевых отличий legacy от не legacy-кода — это наличие тестов. Вы согласны с этим мнением?

Абсолютно согласен! Скажу больше: юнит-тесты — необходимое, но недостаточное условие. И с юнит-тестами можно навалить так, что сам Геракл не разгребёт.
Что для настоящего джедая мастхав, так это:

1. TDD — то есть тесты ДО кода.
   
2. Чистый код (и чистые тесты).
   

Я очень люблю книгу Robert C. Martin «Clean Code» («Чистый код»). Это для меня настольная библия. Категорически всем советую. Кстати, его блог тоже великолепен.