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

Утечек накануне, как обычно, была целая бочка. Apple сама им поспособствовала, отослав журналистам приглашения четырех видов, что привело к обсуждениям, что новых макбуков будет ровно четыре. Место проведения мероприятия – оперный театр Бруклинской музыкальной академии, – показывало, что аудиторией для своих новых гаджетов фирма в первую очередь видит креативных и талантливых людей. Название презентации – «There's More in the Making». В общем, почти всем в индустрии было известно, что нам покажут новые iPad Pro и линейку MacBook. Но Apple на этом не остановилась.

Windows давно упрекают за медлительность файловых операций и создания процессов. А вы когда-нибудь пробовали сделать их ещё медленнее? Эта статья покажет технику, как постепенно замедлять создание процессов в Windows (до бесконечности) незаметно для большинства пользователей!

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

Это реальная проблема, с которой я столкнулся в начале года, и статья объясняет, как я её обнаружил и нашёл обходной путь. Предыдущие статьи о замедлении Windows:

• Замедляем Windows, часть 0: произвольное замедление VirtualAlloc
• Замедляем Windows, часть 1: файловый доступ

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

К изучению темы подключились специалисты из других областей, в том числе химии. И успешно. Профессор теоретической химии Сальваторе Торкуато вместе с теоретиком чисел Мэтью де Курси-Айрлэнд нашли новые шаблоны в распределении простых чисел, о которых раньше не было известно. Оказалось, что распределение простых чисел образует фракталоподобную дифракционную картину, чем-то похожую на картину дифракции у экзотических квазикристаллов.

Материал, перевод которого мы предлагаем сегодня вашему вниманию, представляет собой обновлённую, с учётом положения дел в 2018 году, версию статьи об исследовании фреймворков, которая была опубликована в декабре 2017.

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

Автор статьи, первую часть перевода которой мы публикуем, говорит, что он уже около двух лет работает над крупномасштабным Angular-приложением в Trade Me. В течение последних нескольких лет команда разработчиков приложения постоянно занимается совершенствованием проекта — как в плане качества кода, так и в том, что касается производительности.

В этой серии материалов речь пойдёт о подходах к разработке, используемые командой Trade Me, которые выражены в виде более чем двух десятков рекомендаций, касающихся таких технологий, как Angular, TypeScript, RxJS и @ngrx/store. Кроме того, определённое внимание здесь будет уделено универсальным техникам программирования, которые направлены на то, чтобы сделать код приложений чище и аккуратнее.

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

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



Борьба популяций цифровой плесени под воздействие испепеляющего солнца.

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

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

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

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

В конце июля 2016 года в корпоративном блоге Uber появилась поистине историческая статья о причинах перехода компании с PostgreSQL на MySQL. С тех пор в жарких обсуждениях этого материала было сломано немало копий, аргументы Uber были тщательно препарированы, компанию обвинили в предвзятости, технической неграмотности, неспособности эффективно взаимодействовать с сообществом и других смертных грехах, при этом по горячим следам в Postgres было внесено несколько изменений, призванных решить некоторые из описанных проблем. Список последствий на этом не заканчивается, и его можно продолжать еще очень долго.

Наверное, не будет преувеличением сказать, что за последние несколько лет это стало одним из самых громких и резонансных событий, связанных с СУБД PostgreSQL, которую мы, к слову сказать, очень любим и широко используем. Эта ситуация наверняка пошла на пользу не только упомянутым системам, но и движению Free and Open Source в целом. При этом, к сожалению, русского перевода статьи так и не появилось. Ввиду значимости события, а также подробного и интересного с технической точки зрения изложения материала, в котором в стиле «Postgres vs MySQL» идет сравнение физической структуры данных на диске, организации первичных и вторичных индексов, репликации, MVCC, обновлений и поддержки большого количества соединений, мы решили восполнить этот пробел и сделать перевод оригинальной статьи. Результат вы можете найти под катом.

Вкратце:

• Пруф уже реализован на C++, JS и PHP, подходит для Java.
• Быстрее чем coroutine и Promise, больше фич.
• Не требует выделения отдельного программного стека.
• Дружит со всеми средствами безопасности и отладки.
• Работает на любой архитектуре и не требует особых флагов компилятора.

---

Перевод. Автор оригинала Samer Buna. Оригинал статьи.

---

Когда я впервые узнал о GraphQL после долгого использования различных REST API, то не мог удержаться от твитов такого содержания:

Rest API превратился в REST-in-Peace API. Долгих лет жизни GraphQL

Примечание переводчика – Rest In Peace, RIP – распространенная эпитафия "Покойся с миром". Первое слово в ней пишется так же, как акроним REST.

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

Поймите правильно. Я не собираюсь обвинять GraphQL в убийстве REST или чём-то таком. REST не умрет никогда, также как XML будет жить вечно. Но кто в здравом уме станет использовать XML вместо JSON? На мой взгляд, GraphQL сделает для REST то же самое, что JSON сделал для XML.

«Сколько зрителей придёт на ваш доклад по Java? Зависит от того, выступает ли в то же время в соседнем зале Венкат».

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

Каково это, когда твоя Java-карьера — не «сидеть в офисе», а «постоянно перемещаться»? И что Венкат думает об актуальных Java-вопросах? В октябре он доберётся до Петербурга, и в преддверии этого мы (phillennium, olegchir) взяли у него подробное интервью, где начали с «жизни в самолёте» и советов для начинающих спикеров, а затем перешли к технологиям.

Дефицита технических материалов о Kotlin нет, узнать о корутинах или nullability можно много где. Но остаётся куда менее освещённой другая сторона: а как вообще выглядит процесс разработки языка? Как принимаются решения? Каковы задачи у «самого главного человека»? Остаётся ли у него в жизни время на что-либо ещё?

И сейчас, когда вот-вот выйдет Kotlin 1.3, мы расспросили «самого главного» Андрея Бреслава не про корутины, а про совсем другое: от того, чем он занимался до Kotlin, до того, чем полезна психотерапия.

Предлагаю к прочтению свободный перевод небольшой статьи по практическому применению GraphQL. Оригинал доступен по ссылке (En).

Пару слов о GraphQL

GraphQL это язык запросов для API, который предлагает декларативный подход к получению данных. Он позволяет клиентам запрашивать только нужные данные с веб-сервера и ничего лишнего. Разработанный еще в 2012 году Facebook’ом, которым по-прежнему и поддерживается, GraphQL стал использоваться многими другими крупными и не очень компаниями. Среди прочих Yelp, Shopify и Github.

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

Версии API могут быть головной болью для команд разработчиков. С GraphQL вы можете с этим не беспокоиться. GraphQL позволяет тебе добавить новые поля и типы (это будет обсуждаться позже) в твой GraphQL API, не затрагивая существующие запросы, старые и неиспользуемые же поля могут быть скрытыми от клиентов API. Используя единую эволюционирующую версию, GraphQL API предоставляет вашему приложению постоянный доступ к новым реализациям API и обеспечивают чистую и легко поддерживаемую базу кода.

Всем привет!

Помните эту статью? Раньше мы могли быстро собрать статичную HTML-страничку в каком-нибудь FrontPage и сайт был готов. С этим мог справится любой студент. В более сложном случае, мы писали пару строк на PHP и получали уже целый портал, собранный из разных элементов шаблона на сервере. Затем мы захотели, чтобы наш сайт как-то выделялся на общем фоне и умел чуть-чуть больше. Трон занял его-величество jQuery. Теперь же, мы оказались погребены под завалами фреймворков и библиотек, инструментов сборки, менеджеров зависимостей, препроцессоров и постпроцессоров, особых форматов, языков и стилей программирования, чтобы иметь возможность стряпать простые лэндинги. Все стало слишком сложно. Спикеры на конференциях стали соревноваться в изощренности того, каким еще образом можно сломать нам мозг. Как мы докатились до жизни такой? Чем «раньше» так сильно отличается от «сейчас»? Что нас ждет «потом»? Есть ли в современной веб-разработке некий дзен-стайл, блюдя который, можно, как в старые добрые времена, собрать себе уютный сайтик «на коленке» за пару вечеров, без ковыряния в документации десятка хипстерских технологий-однодневок? Насколько доступны нам простые решения в серьезной промышленной разработке? Куда движется веб-платформа? Предлагаю разобраться.

Что больше всего бросилось в глаза заядлому рубисту, когда он только только начал изучать Elixir с Phoenix-ом.

На хабре есть множество статей про react native, но я не могу понять кем и для кого они написаны. Почти все имеют такой посыл: «Ну, это такой же React как в вебе, только на мобилках». А вот люди, которые занимаются нативной разработкой под мобильные устройства в пролете, ведь разобраться в реакте после Android без двух литров без глубокого изучения никак не получится. А я расскажу за реакт опираясь, внезапно, не на веб разработку, а на Android. Всем заинтересованным добро пожаловать под кат.

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

Кстати, функциональные программисты правы. Чистые функции — это хорошо. Но есть одна проблема…

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

Мы начинаем публикацию серии материалов, которые представляют собой поэтапный перевод руководства по Node.js для начинающих. А именно, в данном случае «начинающий» — это тот, кто обладает некоторыми познаниями в области браузерного JavaScript. Он слышал о том, что существует серверная платформа, программы для которой тоже пишут на JS, и хотел бы эту платформу освоить. Возможно, вы найдёте здесь что-то полезное для себя и в том случае, если уже знакомы с Node.js.

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



Сегодня мы обсудим особенности Node.js, начнём знакомство с экосистемой этой платформы и напишем серверный «Hello World».