Занимаясь переводами Кнута, я наткнулся на упоминание очень интересного свойства нашей вселенной. Рождение гигантской компоненты. Каждый встречался с этим феноменом. Я, например, помню коробочки с рыболовными крючками. Когда крючков было 5-15 все нормально, но есть определенная критическая масса, после которой получался единый комок. Интуитивно я чувствую, что это очень важный феномен, который проявляется во многих дисциплинах — от теории информации, до молекулярной химии и биотехнологии. Предлагаю вашему вниманию перевод легкой и наглядной статьи на эту тему. Слово Brian Hayes.



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

На днях я сделал открытие: если вы захватите одну из выброшенных скоб и поднимите ее, целый клубок спутанного искореженного металла поднимется вслед за ней, оставляя лишь пару скоб на дне чаши. Когда я заметил это, я сначала подумал «Хм, это забавно». Потом «О, конечно: Erdős-Rényi». А третей мыслью… ну я все еще работаю над ней, а еще над четвертой, пятой и шестой.

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

Этот материал мы подготовили для JavaScript-программистов, которые только начинают разбираться с «Promise». Обещания (promises) в JavaScript – это новый инструмент для работы с отложенными или асинхронными вычислениями, добавленный в ECMAScript 2015 (6-я версия ECMA-262).

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

В 1971 году СССР доставили на Марс первые в мире планетоходы «на лыжах», которые должны были щупом (динамический пенетрометр и гамма-лучевой плотномер) ткнуть поверхность, и сказать — Марс твердый или жидкий пыльный. Первый аппарат разбился 27 ноября, второй совершил мягкую посадку 2 декабря, но марсоходик не смог выбраться из «скорлупы» посадочного модуля, поэтому попытку не засчитали.

Прошло 25 лет.
4 июля 1997 года на Марс прилетел американский аппарат и привез «пришельца» с первым багом.


Кадр из к/ф «Марсианин». Главный герой держит в руках марсоход Sojourner

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

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

У созданий всего 64 гена, но можно ввести всего лишь 10 первых.

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

Мне хочется рассказать тебе о проблеме в нашем сообществе.

Я участвовал во множестве открытых проектов, таких как Babel, Flow, Yarn, Lerna, и других. Как разработчик, мне посчастливилось стать частью самых лучших времён сообщества, равно как и худших.

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

Но боюсь, это не всё, с чем я сталкивался.

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

Но врожденные любознательность и энтузиазм довели меня до того, что я стал одним из разработчиков Synaptic — проекта фреймворка для построения нейронных сетей на JS с 3к+ звезд на GitHub. Сейчас мы с автором фреймворка занимаемся созданием Synaptic 2.0 с ускорением на GPU и WebWorker-ах и с поддержкой почти всех основных фич любого приличного NN-фреймворка.

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

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

В прошлой своей статье я рассказал про построение простых графиков с помощью библиотеки d3, с ее же помощью планировал отрисовывать и карты, но поэкспериментировав с d3, Raphael и paper.js понял что велосипедостроения избежать не удастся и переделал отрисовку на HTML Canvas, о чем и хочу рассказать в данной статье.

Сальвадор Дали, Дезинтеграция постоянства памяти. 1952—1954. Холст, масло.

Всем привет. Кто-то из вас, возможно, уже знаком с СУБД для данных в оперативной памяти, но на всякий случай — по ссылке можно найти их общее описание. Если вкратце, такие СУБД хранят данные целиком в оперативной памяти. Что это означает? Каждый раз, отправляя запрос на поиск или обновление данных, вы обращаетесь только к оперативной памяти в обход жесткого диска — на нем никакие операции не производятся. И это хорошо, потому что оперативная память работает намного быстрее любого диска. Примером такой СУБД является Memcached.

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

Можно ли объединить достоинства хранения данных в оперативной памяти с надежностью проверенных временем СУБД вроде MySQL или Postgres? Конечно! Повлияет ли это на производительность? Вы удивитесь, но нет!

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

Наиболее частая ситуация, которую я могу привести в пример — str_repeat('очень-', 20) старый код, не знающий даже классов, планируется перенести или частично использовать в современном фреймворке, но переписывать тысячи строк и десятки зависимостей нет времени. Такое бывает, когда заказчик вдруг решает существенно модернизировать или развивать проект, который 10+ лет работал без изменений, а сапортил его один парттайм-олдскул-программист изредка перезагружая пару-тройку сервисов и восстанавливая пароли.

Вячеслав Москаленко (Ленвендо)

Я буду рассказывать вам об инструментах высоконагруженных проектов, кэшировании, в частности, о memcached, Redis-е и о сервисе очередей RabbitMQ или в простонародье «кролике».

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

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

О кэшировании. Думаю, многие из вас хоть что-то кэшировали в своих веб-проектах, поэтому все будет очень просто и доступно.

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

Когда я стал применять такой принцип, я развил в себе привычку писать очень маленькие функции — обычно не больше нескольких строк. Любая функция длиннее шести строк уже попахивает. Вполне обычное дело для меня — иметь функцию с одной строчкой кода. Кент Бек показал мне когда-то пример из оригинальной системы Smalltalk, и это помогло мне по-настоящему понять, что размер — это не важно. Smalltalk в те годы работал на черно-белых машинах. Если нужно было подсветить текст или графику, то приходилось реверсировать видео. Класс в Smalltalk, отвечающий за графику, содержал метод 'highlight', и в его реализации была лишь одна строка — вызов метода 'reverse'. Название метода было длиннее реализации, но это не имело значения, потому что между намерением и реализацией этого кода — большое расстояние.

Тема написания своего ЯПа не дает мне покоя уже около полугода. Я не ставил перед собой цель "убить" CoffeeScript, TypeScript, ELM, тысячи их, я просто хотел понять кухню и как они вообще пишутся.

К моему неприятному удивлению, большинство из этих языков используют Jison (Bison для JavaScript), а это не совсем попадало под мою задачу — "понять", так как по сути дела Jison делает все за вас, собирает AST по заданным вами правилам (Jison как таковой отличный инструмент, который делает за вас львиную долю работы, но сейчас не о нем).

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

Стоит заметить, что данное руководство не привязано к JavaScript, он выбран исключительно из соображений скорости разработки и читаемости, так что вы можете написать свой "лисп"/"питон"/"ваш абсолютно новый синтаксис" на любом знакомом вам языке.

Также до момента написании компилятора (в нашем случае транслятора), процесс написания языка не отличается от процессов создания языков компилируемых в ASM/JVM bitcode/LLVM bitcode/etc, а это значит, что данное руководство не ограничивается созданием языка трансляцируемого в JavaScript.

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

За последние годы Node.js значительно повысил свой статус от экспериментальной технологии до основы для серьезных проектов. Node.js дает возможность построить достаточно сложные, высоконагруженные приложения на простом, элегантном и, самое главное, легковесном механизме. Но прежде всего Node.js – это совершенно увлекательная и захватывающая вещь, с которой по-настоящему интересно работать!

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

Давайте мысленно вернемся во времена php4, когда получили своё развитие wordpress, bitrix и миллионы других CMS и домашних страничек.

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

Некоторое время назад было достаточно много шума в Интернете и вопросов на конференциях по поводу того, являются ли задачи по рефакторингу кода такого же рода задачами, как и все остальные, с необходимостью описывать их, помещать в Backlog, а затем перемещать в новый спринт. Я считаю что это плохой идеей, даже в случае непомерно разросшегося «технического долга» проекта. И вот почему:

Когда начинается новый проект — его код чист и прекрасен. Самое время проектировать красивые абстракции, писать хорошие интерфейсы и профессиональные реализации. Жизнь прекрасна! Наш проект тоже.

Известно, что на старых картах, на неизведанных территориях, часто помещали зловещее предупреждение: «Здесь живут драконы». Вероятно, смысл этого предупреждения состоял в том, что не стоит входить в это пространство мира, не будучи готовыми сражаться с внушающим ужас противником. Всё что угодно может случиться на этих загадочных просторах, и нередко такое «что угодно» может закончиться очень плохо.

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

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

Вот семь из устрашающих уголков мира программирования, на которых легко можно написать: «Здесь живут драконы».