Скачать файл с кодом и данные можно в оригинале поста в моем блоге

В языке Wolfram Language есть четыре совершенно потрясающие функции: FindSequenceFunction, RSolve, DifferenceRootReduce и FindFormula. В этой статье мы обсудим их возможности и поговорим о функциях, тесно с ними связанных — для поиска параметров линейной рекурсии FindLinearRecurrence (коэффициентов линейного рекуррентного уравнения), производящих функциях GeneratingFunction и Z-преобразовании ZTransform.

Первая функция — FindSequenceFunction — по последовательности чисел ищет выражение для её n-го члена не требуя вообще ничего более.

Hold @ FindSequenceFunction[{1, 1, 2, 3, 5, 8, 13}, n]

FindSequenceFunction[
{-2, 4Sqrt[Pi],
-16, 16Sqrt[Pi],
-128/3, 32Sqrt[Pi],
-1024/15, 128Sqrt[Pi]/3,
-8192/105, 128Sqrt[Pi]/3},
n]

О чем это

А как можно на четвёртом десятке и с аверсией к алгебре наверстать требуемый материал первых курсов университета?

Безумству храбрых поем мы песню!

Целевой аудиторией Путеводителя являются те, кто внезапно заинтересовался математикой или чувствует потребность повысить свою профессиональную эффективность, но по какой-либо причине не имеет возможности отдать несколько лет своей жизни академическому образованию. Если у вас возникла потребность разобраться, но фундаментальных знаний катастрофически не хватает, и вы чувствуете себя иностранцем в стране математики, где говорят на непонятном языке, попробуйте пройти этот путь в качестве туриста. Весь маршрут представляет собой обзорную экскурсию и рассчитан на несколько дней, максимум две недели. Для сравнения: полный академический курс составляет около пяти лет. Конечной целью предлагаемого маршрута является знакомство с принципами одного узкоспециального раздела — эллиптической криптографии. Однако до конца идти не обязательно, если этот раздел лежит вне сферы ваших интересов или вы столкнулись с серьезными трудностями или опасностями. Но, раз уж вы взяли в руки Путеводитель, всё же постарайтесь дойти хотя бы до конца раздела «Язык формул».

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

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

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

---

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

«Направленный ациклический граф? Никогда об этом не слышал. Не думай, что все обо мне знаешь!», вы можете сказать, но именно этот граф делает возможным контроль версий. Да, Git представляет из себя ациклический граф. В этой статье я поделюсь с вами знаниями о направленных ациклических графах (Directed Acyclic Graphs, DAG), а затем покажу, как написать свой собственный.

Всем привет! Меня зовут Юрий Лилеков, я работаю в Server Team Badoo. На днях мне попалась довольно интересная статья о новой семантике exactly-once в Apache Kafka, которую я с радостью для вас перевёл.

Gonkey тестирует наши микросервисы в Lamoda, и мы подумали, что он может протестировать и ваши, поэтому выложили его в open source. Если функциональность ваших сервисов реализована преимущественно через API, и используется JSON для обмена данными, то почти наверняка Gonkey подойдет и вам.

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

Приветствую бойцов невидимого бэкенда!

Вы уже почитали обзоры MongoDB. Вероятно, прошли отличные онлайн-курсы на university.mongodb.com. Конечно, у вас уже есть многообещающий проект-прототип с использованием MongoDB.

Что мы можем ждать от MongoDB на этом этапе?

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

И вот, вы готовы ввязаться в бой — выпустить проект на публику.

Слышали ли вы когда-нибудь про Вампуса? Независимо от ответа — добро пожаловать в его владения!

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

Разработчик Кристоф Вердо рассказывает об онлайн-курсе ‘Mastering Web 3.0 with Waves’, который он недавно прошел.



Расскажите немного о себе. Чем вас заинтересовал этот курс?

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

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

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

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

На РИТ++ Никита Соболев (sobolevn) выступил, как он сам назвал это, с проповедью на тему качества кода и процессов в компании. Особо впечатлительных просим налить себе ромашкового чаю, но отойти от экранов не предлагаем. Вы можете не соглашаться ни с одним из тезисов, настаивать, что трёп о сериалах — залог здоровой атмосферы в коллективе, и утверждать, что вам не нужны строгие рамки линтера и CI, чтобы писать хороший код. Но если вы хоть раз винили окружающих в неудачах на работе, вам стоит прочитать или посмотреть рассказ Никиты.

Работали ли вы когда-нибудь на плохой работе?

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



Когда я говорю, все плохо, я имею в виду, что у нас был:

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

Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.

Ровно 15 лет назад, в этот самый день, своими дрожащими коленками я переступил порог офиса небольшого провинциального интернет-провайдера. Моя первая настоящая работа в качестве программиста. Знаний почти нет. Тонкий испуганный голосок откуда-то из желудка советует развернуться и убежать подальше, пока окончательно не опозорился. Глубокий вдох-выдох, и вот генеральный директор уже ведет меня в небольшую комнатку-подвальчик, показывает на полуразобранный компьютер, видавший лучшие времена: «Это твое рабочее место. Устраивайся». Так началась моя карьера.

Но перенесемся в настоящее. Сейчас я пишу эти строки, сидя в удобном офисе престижного БЦ в центре Москвы. За плечами работа с крупными международными брендами и разработка сложных fintech приложений. Сотни книг прочитано и десятки статей написано. Мания величия давно вылечена. Менеджерские позиции опробованы и отвергнуты. Душевное равновесие найдено. Любовь к профессии сохранена. Однако это не статья из серии “Какой я молодец. Делай, как я и тоже будешь молодцом”. Эта статья о том, какие ошибки я совершал и что можно было сделать лучше. Эта статья — ретроспектива моей карьеры.

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

Что там будет под капотом, ни одна живая душа уже не поймет. Команда «хреновина» интерпретируется в абзац с описанием, который интерпретируется в ключевые слова, который интерпретируется в набор векторных обозначений, который интерпретируется в какой-нибудь С, который скомпилируется в…

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

Программистами станут лощеные гуманитарии с «высокими вербальными способностями, коммуникативными навыками и умением быть няшей в команде». Слава богу до этого дня, как до Аляски на упряжке, но каждый раз изобретая очередной Kotlin, мы этот день приближаем.

Просто я задумался — а не стали ли наши ЯПы уже чем-то таким? Чуть более умным эквивалентом фразы «компьютер, сделай хреновину». Кучей формализованных протоколов для электричества, про которое мы уже забыть забыли. Штукой, которая все сильнее рвет нашу связь с механической реальностью.

Я часто слышу фразу: «Фил, отступись, хватит думать обо всякой чепухе». Но блин, будь проклят тот день, когда на Хабре напишут «хватит думать».

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Perils of Constructors" автора Aleksey Kladov.

Один из моих любимых постов из блогов о Rust — Things Rust Shipped Without авторства Graydon Hoare. Для меня отсутствие в языке любой фичи, способной выстрелить в ногу, обычно важнее выразительности. В этом слегка философском эссе я хочу поговорить о моей особенно любимой фиче, отсутствующей в Rust — о конструкторах.

Что такое конструктор?

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

1. Вы устанавливаете инварианты в конструкторе.
2. Каждый метод заботится о сохранении инвариантов.
3. Вместе эти два свойства значат, что можно думать об объектах как об инвариантах, а не как о конкретных внутренних состояниях.

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

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

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

Мы будем под кэшированием понимать сохранение результатов вычислений в ответ на некоторые запросы. То есть, повторный результат запроса не всегда вычисляется заново, но иногда берется из таблицы, называемой кэшем. Сложно переоценить роль кеширования в современных системах. При этом часто возникает проблема, связанная с недостатком памяти. Действительно, что делать, если запросов много, а памяти хватает лишь для хранения ограниченного числа результатов? В этом случае, как правило, кеш стрится следующим образом. Фиксируется размер кэша, пусть будет N, и сохраняются результаты только для N самых «популярных» запросов.

То есть сохраняются результаты вычислений, которые скорее всего запросят заново.
Как определять эти «популярные» запросы? Наиболее известным способом является LRU, о котором я и расскажу в этой статье.

Кому-то не нравился Redux в React из-за его имплементации на JS?

Мне он не нравился корявыми switch-case в reducer'ах, есть языки с более удобным pattern matching, и типы лучше моделирующие события и модель. Например, F#.
Эта статья — разъяснение устройства обмена сообщениями в Elmish.

Привет, я Катя, я не работаю уже год.



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

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



Часть 1: Практические рекомендации по разработке масштабных React-приложений. Планирование, действия, источники данных и API

Часть 2: Практические рекомендации по разработке крупномасштабных React-приложений. Часть 2: управление состоянием, маршрутизация

Всем привет! Мы запустили новый набор на курс «Алгоритмы для разработчиков» и сегодня хотим поделиться интересным переводом, подготовленным для студентов данного курса.



В деревьях поиска, таких как двоичное дерево поиска, AVL дерево, красно-чёрное дерево и т.п. каждый узел содержит только одно значение (ключ) и максимум двое потомков. Однако есть особый тип дерева поиска, который называется B-дерево (произносится как Би-дерево). В нем узел содержит более одного значения (ключа) и более двух потомков. B-дерево было разработано в 1972 году Байером и МакКрейтом и называлось Сбалансированное по высоте дерево поиска порядка m (Height Balanced m-way Search Tree). Свое современное название B-дерево получило позже.