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

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

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

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

Введение

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

Видеоигры быстро становятся изумительным симулякром реальности. Мы можем блуждать по невообразимым мирам, общаться с правдоподобными персонажами и наносить нацистам убедительно выглядящие побои. Тем не менее, видеоигры всё ещё испытывают проблемы со снятием одежды.

Посмотрите на сцену из игры 2010 года Mass Effect 2 с раздевающимся Джейкобом. На первый взгляд кажется, что он стянул рубашку, как это сделал бы любой человек, демонстрируя невидимому оператору заработанные в боях кубики пресса. А теперь приглядитесь внимательно: к моменту, когда его руки движутся по телу, «снимая» рубашку, её уже нет. Игра переключилась с одетой на раздетую модель с помощью иллюзии, заставляющей игрока подумать, что он снимает рубашку.

Однажды вы задумаетесь, как превратить скрипт или приложение в Windows-службу. Скорее всего, задача окажется не такой уж тривиальной – приложению как минимум потребуется специальный интерфейс для получения команд от системы. А раз есть требования и ограничения, то есть и скрипты, и милые сердцу костылики для преодоления.

Статья будет полезна тем, кто, как и я — «программист не настоящий».

«Подготовленный человек тоже наступает на грабли.
Но с другой стороны — там, где ручка.»

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

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

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

Самая громкая новость, прозвучавшая на крупнейшей в мире международной компьютерной выставке: второе поколение AMD Ryzen Threadripper уже здесь. В сегодняшнем анонсе много изображений, описание скоростей и каналов, спецификации и объявления «unboxing», одним словом, прямой намек на открытие предварительных заказов за неделю до начала розничной продажи (на момент написания оригинальной статьи). Я с тяжелым грузом на сердце спешу уведомить читателя, что из-за эмбарго на unboxing до начала продаж мы попросту не имеем права обнародовать то, как будут работать новые чипы. Мы рассмотрим спецификации, обсудим дизайн и продемонстрируем материалы, которые AMD предоставила в своем пресс-кит.

Заголовок статьи звучит как epic fail, но на самом деле все не так однозначно. Да и в общем и целом эта история закончилась весьма позитивно, хоть и не в Google. Но это уже тема для другой статьи. В этой же статье я расскажу о трех вещах: каким образом проходил мой процесс подготовки, каким образом проходили интервью в Google и почему же на мой взгляд все не так однозначно, как может показаться.

Я не искал неприятностей. Не запускал процесс сборки Chrome тысячу раз за выходные, а только занимался самыми обычными задачами 21-го века — просто писал электронное письмо в 10:30 утра. И вдруг Gmail подвис. Я продолжал печатать несколько секунд, но на экране не появлялось никаких символов. Затем внезапно Gmail отвис — и я вернулся к своему очень важному письму. Но впоследствии всё повторилось, только на этот раз Gmail ещё дольше не отвечал запросы. Это странно…

Трудно устоять перед возможностью провести хорошее расследование, но в данном случае вызов особенно силён. Ведь я в Google работаю над улучшением производительности Chrome для Windows. Обнаружить причину зависания — моя работа. И после множества фальстартов и тяжёлых усилий мне всё-таки удалось выяснить, как Chrome, Gmail, Windows и наш IT-отдел вместе помешали мне набрать электронное письмо. По ходу дела нашёлся способ сэкономить значительное количество памяти для некоторых веб-страниц в Chrome.

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

И почему всё же стоит использовать её

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

Оценка трудозатрат на разработку и ценности (отдачи от трудозатрат) — главный элемент приоритизации в продуктового бэклога: это простой понятный подход, а потому очень популярный. У вас наверняка есть 2 такие колонки в продуктовом бэклоге (и даже если нет, то стоит их добавить):

Для тех, кто интересуется темой смарт-контрактов, ответ на вопрос, заданный в заголовке, лежит на поверхности: на сегодняшний день контракты не имеют достоверного и полного источника информации о происходящем в реальном мире. Вследствие этого складывается прескверная ситуация: мы можем описать в смарт-контракте сложную логику, а блокчейн обеспечит нам её безоговорочное исполнение. И вот, казалось бы, мы в шаге от того, чтобы избавиться от необходимости в третьей стороне при заключении договоров — именно это имелось в виду под словами «изменить мир» в заголовке. Однако любой логике, описывающей процессы реального мира, нужно знать, что в этом мире происходит. Таким образом, от «революции доверия» нас отделяет последняя преграда в виде отсутствия поставщиков информации или оракулов, как их называют в мире смарт-контрактов. Решение этой задачи дало бы колоссальный импульс распространённости и применимости смарт-контрактов. В противном случае эта технология рискует навсегда остаться лишь площадкой для реализации ICO.



Способности, не находящие применения, превращаются в ничто.
Стен Надольный

Всем привет. В статье хочу описать свой эксперимент по созданию «искусственной жизни» на компьютере.

Как это выглядит?

картинка кликабельна

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

Ну а дальше за работу принимается эволюция и естественный отбор.

А мне остаётся только наблюдать за развитием мира.

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

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

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

Внутреннее устройство кода — это самое интересное в проекте.

Код должен быть простым и выдерживать различные модификации (случайное изменение любого элемента в коде) над собой без синтаксических ошибок.

У всех была детская мечта. Лично я мечтал создать игру для моей первой консоли: Nintendo Game Boy. Сегодня моя мечта реализовалась — я выпустил первую игру для Game Boy на настоящем картридже: Sheep It Up!

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

• Часть 1: использованные инструменты/технические сложности/сложности с графикой
• Часть 2: ограничения звука/создание картриджей/отзывы игроков

Игра

«Sheep It Up!» — это аркадная игра, в которой овца должна взбираться вверх, приклеиваясь к летающим полоскам липучки. Концепция проста, но игра быстро становится довольно сложной: как далеко вы сможете забраться, не упав?

Автор: Александр Кашеверов, Senior JavaScript Developer

Добро пожаловать и приятного чтения!

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

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

Для лучшего понимания — необходимо знание JavaScript и общее представление о работе веб.

Конечно, у визуализации данных есть своя история (в статье мы этого касаться не будем), если интересно — можно ознакомиться, например, здесь.

Моя статья, вероятно, не всеобъемлющая, поэтому пишите комментарии и личные сообщения, я готов выслушать критику и дополнить материал.

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

Периодически мы публикуем материалы, которые так или иначе касаются использования промисов в JavaScript.


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

Поэтому, если вы хотите лучше понять промисы, мы предлагаем вашему вниманию перевод очередной статьи, посвящённой этой теме. Её автор говорит, что он последние 10 лет занимался разработкой на Java и PHP, но всё это время с интересом поглядывал на JavaScript. Недавно он решил всерьёз заняться JS и первой заинтересовавшей его темой стали промисы.



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

Это рассказ о том, как написать свою игру на Corona.
Уровень вхождения — минимальный (и ботаник с кафедры алгебры поймет).

Я напомню, что Corona — это движок для создания 2D игр на все платформы и, touch-touch, сегодня День космонавтики. Сюжет для игры выбран соответсвующий и, разумеется, мы повторяем за первым космонавтом

-Поехали!

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

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

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

Помимо интерактивных касс, появляются интересные схемы развлекательных комплексов с подробным описанием и подробностями о акциях или скидках.

Насколько это безопасно?

Когда я, так сказать, прошёлся по Интернету, я заметил одну интересную особенность. Все парадигмы программирования, где-либо обсуждаемые, воспринимаются людьми совершенно спокойно. Если, например, говорят про процедурное программирование, то говорят про него абсолютно спокойно. То же самое — про модульное программирование. Декларативное программирование — никаких бурь, волнений или холиваров. Функциональное программирование — то же самое.

И только вокруг ООП не утихают бури.