Глубока ли кроличья нора?



Сколько минут вам потребуется, чтобы понять в чем фишка?

Фрэнсис Бэкон в 1620 году разделил источники человеческих ошибок, стоящих на пути познания, на четыре группы, которые он назвал «призраками» или «идолами» (лат. idola).

• «Призраки рода» проистекают из самой человеческой природы, они не зависят ни от культуры, ни от индивидуальности человека. «Ум человека уподобляется неровному зеркалу, которое, примешивая к природе вещей свою природу, отражает вещи в искривлённом и обезображенном виде».
• «Призраки пещеры» — это индивидуальные ошибки восприятия, как врождённые, так и приобретённые. «Ведь у каждого, помимо ошибок, свойственных роду человеческому, есть своя особая пещера, которая ослабляет и искажает свет природы».
• «Призраки площади (рынка)» — следствие общественной природы человека, — общения и использования в общении языка. «Люди объединяются речью. Слова же устанавливаются сообразно разумению толпы. Поэтому плохое и нелепое установление слов удивительным образом осаждает разум».
• «Призраки театра» — это усваиваемые человеком от других людей ложные представления об устройстве действительности. «При этом мы разумеем здесь не только общие философские учения, но и многочисленные начала и аксиомы наук, которые получили силу вследствие предания, веры и беззаботности». [Wikipedia]

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

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

Перевод статьи Синди Шридхаран.

В этой статье автор собирается:

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

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

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

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Цель данной статьи — вместе с читателем написать окружение для разработки современных веб-приложений, последовательно добавляя и настраивая необходимые инструменты и библиотеки. По аналогии с многочисленными starter-kit / boilerplate репозиториями, но наш, собственный.

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

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

Цель данной статьи — вместе с читателем написать окружение для разработки современных веб-приложений, последовательно добавляя и настраивая необходимые инструменты и библиотеки. По аналогии с многочисленными starter-kit / boilerplate репозиториями, но наш, собственный.

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

Как-то для своих некоторых планов мне потребовалось сделать небольшую песочницу в 2D пространстве с базовыми возможностями:

1. Передвижение по игровому миру
2. Физика при движении, столкновения
3. Создание блоков
4. Удаление блоков

Графическое исполнение меня не беспокоило, поэтому я решил оформить все в серых тонах, выглядит это так:

После нескольких лет работы с Git я обнаружил, что постепенно стал переходить на всё более сложные Git-команды в рабочем процессе. Вскоре после того как я открыл для себя Git rebase, я тоже быстро внедрил эту команду в повседневные задачи. Те, кто знаком с этой процедурой, знают, насколько это мощный инструмент и какой это соблазн — постоянно им пользоваться. Но вскоре оказалось, что rebase влечёт за собой ряд неочевидных на первый взгляд трудностей. Но прежде чем обсудить их, хочу быстро рассмотреть различия между merge и rebase.

Дизайн — это фашизм. Фашизму нужна питательная среда. Он начинает раскрываться в полной мере только на крупных масштабах. Идеальная среда для фашизма — это большая компания с огромным количеством продуктов. Например, Google или… Альфа-Банк. Фашизм априори не гибок…

Берем что-то всем давно известное и делаем это удобным и красивым

Представляем вашему вниманию react-beautiful-dnd

Функция перетаскивания (drag&drop) — это интуитивный способ перемещения и переупорядочивания элементов. В Atlassian недавно выпустили react-beautiful-dnd, которая делает перетаскивание (drag&drop) внутри списков в вебе красивыми, естественными и доступными.

Вышел React 16! Рассказывая об этом событии, можно упомянуть множество замечательных новостей (вроде архитектуры ядра Fibers), но лично меня больше всего восхищают улучшения серверного рендеринга. Предлагаю подробно всё это разобрать и сравнить с тем, что было раньше. Надеюсь, серверный рендеринг в React 16 понравится вам так же, как он понравился мне.

Этот пост — список забавных и хитрых примеров на JavaScript. Это отличный язык. У него простой синтаксис, большая экосистема и, что гораздо важнее, огромное сообщество.

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

---

Перевод статьи Sashko Stubailo GraphQL vs. REST

---

Два способа отправки данных по протоколу HTTP: в чем разница?

GraphQL часто представляют как революционно новый путь осмысления API. Вместо работы с жестко определенными на сервере конечными точками (endpoints) вы можете с помощью одного запроса получить именно те данные, которые вам нужны. И да — GraphQL гибок при внедрении в организации, он делает совместную работу команд frontend- и backend-разработки гладкой, как никогда раньше. Однако на практике обе эти технологии подразумевают отправку HTTP-запроса и получение какого-то результата, и внутри GraphQL встроено множество элементов из модели REST.

Так в чем же на самом деле разница на техническом уровне? В чем сходства и различия между этими двумя парадигмами API? К концу статьи я покажу вам, что GraphQL и REST отличаются не так уж сильно, но у GraphQL есть небольшие отличия, которые существенно меняют процесс построения и использования API разработчиками.

Так что давайте сразу к делу. Мы определим некоторые свойства API, а затем обсудим, как они реализованы в GraphQL и REST.

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

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


Сцена из Minecraft, до и после добавления нескольких шейдеров.

Задача этого туториала

Иногда программирование шейдеров представляется загадочной чёрной магией и его часто понимают неправильно. Существует множество примеров кода, демонстрирующих создание невероятных эффектов, но в которых практически нет объяснений. В своём руководстве я хочу восполнить этот пробел. Я сосредоточусь в основном на базовых принципах создания и понимания кода шейдеров, чтобы вы смогли с лёгкостью настраивать, сочетать или писать свои собственные шейдеры с нуля!

Выступления и посты в блогах о производительности JavaScript часто обращают внимание на важность мономорфного кода, однако обычно не дается внятного никакого объяснения, что такое мономорфизм/полиморфизм и почему это имеет значение. Даже мои собственные выступления зачастую сводятся к дихотомии в стиле Невероятного Халка: «ОДИН ТИП ХОРОШО! ДВА ТИП ПЛОХО!». Неудивительно, что когда люди обращаются ко мне за советом по производительности, чаще всего они просят объяснить, что на самом деле такое мономорфизм, откуда берется полиморфизм и что в нем плохого.

Ситуацию осложняет еще и то, что само слово «полиморфизм» имеет множество значений. В классическом объектно-ориентированном программировании полиморфизм связан с созданием дочерних классов, в которых можно переопределить поведение базового класса. Программисты, работающие с Haskell, вместо этого подумают о параметрическом полиморфизме. Однако полиморфизм, о котором предупреждают в докладах о производительности JavaScript – это полиморфизм вызовов функции.

Я объяснял этот механизм столькими различными путями, что наконец-то собрался и написал данную статью: теперь можно будет не импровизировать, а просто дать на нее ссылку.

_{Я также попробовал новый способ объяснять вещи – изображая взаимодействие составных частей виртуальной машины в виде коротких комиксов. Кроме того, данная статья не покрывает некоторые детали, которые я посчитал незначительными, излишними или не связанными напрямую.}

Предлагаю общественности мой перевод статьи Dan Pupius'а об архитектура сервиса Medium и используемых технологиях. Хочу особо отметить, что статья является переводом, поэтому местоимение "я", используемое в тексте далее относится к автору оригинального текста, а не к переводчику.

Фон

Medium это сеть. Это место, где обмениваются историями и идеями, которые важны — место, где вы развиваетесь, и где люди провели 1.4 миллиарда минут — 2.6 тысячелетия.

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

Я руковожу инженерной командой. Раньше я работал инженером в Google, где я работал над Google+ и Gmail, а также был одним из со-основателей проекта Closure. В прошлой жизни я гонял на сноуборде, прыгал из самолёта и жил в джунглях.

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



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

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

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

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

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

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

Как писал Уинстон Черчилль, ярый любитель хобби:

Нет смысла говорить уставшим «мускулам разума»: «я дам вам хорошенько отдохнуть», «пойду прогуляюсь» или «лягу и не буду ни о чём думать». Разум всё равно остаётся занятым. Если вы что-то взвешивали и прикидывали, он так и будет взвешивать и прикидывать. Если вы волновались, он будет волноваться… Бесполезно спорить с разумом, находящимся в таком состоянии. Один талантливый психолог из США сказал: «волнение – это эмоциональный спазм. Разум цепляется за что-то и не отпускает». Можно лишь аккуратно внедрить что-то другое в эту конвульсивную хватку. И если это что-то выбрано правильно, если оно сопровождается освещением другой области интересов, то постепенно, а иногда и довольно быстро, чрезмерная хватка ослабляется и начинается процесс восстановления и заживления.

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

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

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

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

Ну все, завязываю со вступлением.

Два года назад я начал негласно исполнять роль iOS-lead в компании Touch Instinct и формированием стабильной работы iOS-отдела. Спустя полгода это трансформировалось в официальную должность. Из-за отсутствия опыта у меня возникало огромное количество проблем, которые вызывали жжение в области верхней части кресла. Это происходило из-за ряда факторов:

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

Если вы стали лидом и первоначальная эйфория сменилась небольшим горением и унынием, то пара советов не будет лишней.