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

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

Заранее благодарю, если укажете на какие-то неточности перевода, если таковые заметите. А вот, собственно, сам материал автора.

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

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

Вот только вопрос в том, как же развить это самое дизайн мышление?

Простая стратегия.

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

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

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

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

Зависимости. Дженерики. Они часто звучат в списке проблем в Go сообществе, но есть одна проблема, о которой вспоминают довольно редко — организация кода вашего пакета.

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

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

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

В предыдущем посте мы разобрались, как работать с потоками байт, но иногда нам нужно работать с конкретным набором байт в памяти. Хотя слайсы байт вполне подходят для многих задач, есть немало случаев, когда лучше использовать пакет bytes. Также мы рассмотрим сегодня и пакет strings, так как его API практически идентичен bytes, только он работает со строками.

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

Часть 1 Часть 2 Часть 3 Часть 4

Сервисы

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

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

По умолчанию npm публикует в registry весь модуль целиком. За исключением явно указанных в .gitignore файлов. Это отбрасывает зависимости, но все равно позволяет куче не очень нужных файлов просочиться в опубликованное. После чего благодарные пользователи ждут, пока все это скачается. Для grunt, кстати, ждать придется порядка 6 мегабайт. А он такой обычно не один.

Я решил разобраться, как измерить размер своих модулей после публикации и, по возможности, этот размер уменьшить. В качестве примера буду использовать модуль check-more-types, который содержит всего несколько файлов. Плюс юнит тесты и документацию, которая собирается в README markdown файл.

Наверняка вы видели в моей ленте на Dribbble или Behance за последние 4 месяца много красочных и бессмысленных интерфейсов :) Если нет, то это был 12 недельный sketch марафон в котором я на протяжении 12 недель (включая выходные) делал по 1 shot каждый день. Ниже я расскажу о том что из этого вышло.

Мы в Хекслете любим разрабатывать не только прикладные курсы, но и более фундаментальные (например, про алгоритмы или операционные системы). Но мы пока не спускались ниже уровня ОС в иерархии абстракций. А там, внутри, столько всего интересного! Для многих людей, да даже для многих профессиональных программистов остаются загадкой процессы, происходящие внутри микропроцессора, на уровне отдельных транзисторов.

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