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

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

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

Время жизни (lifetime)

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

Немного о bfc

Brainfuck — очень глупый язык. Там есть лента из 30к ячеек, по байту каждая. Команды bfc это:

• Передвижение по ленте влево и вправо (символы < и >)
• Увеличение и уменьшение значения в ячейке (символы + и -)
• Ввод и вывод текущей ячейки (символы . и ,)
• И цикл while, который продолжается пока значение в текущей ячейке не ноль. [ и ] это начало и конец цикла соответственно

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

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

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

В этой статье мы научимся писать полноценный gRPC сервис на Go на примере сервера авторизации с полноценной архитектурой, готовой к продакшену. Мы напишем как серверную часть, так и клиентскую. В качестве клиента мы возьмём мой сервис — URL Shortener, о котором у меня также есть статья и видео-гайд на ютубе. Попутно мы познакомимся с базовыми подходами к работе с авторизацией. И в конце настроим автоматический деплой сервиса с помощью GitHub Actions на удалённый сервер.

Видео-версия этого гайда с более подробными объяснениями

Исходный код проекта: https://github.com/GolangLessons/sso

Итого, наш план:

• Напишем простой, но полноценный gRPC-сервис
• Разберемся с базовыми принципами работы авторизации — чтобы не было скучно
• Настроим автоматический деплой в прод — потому что руками деплоить лень
• Подружим его с уже готовым сервисом URL Shortener — чтобы был практический смысл
• Напишем полноценные функциональные тесты

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

Кратко обо мне: меня зовут Николай Тузов, я много лет занимаюсь разработкой на Go, очень люблю этот язык. Также веду свой YouTube-канал.

Несколько лет назад я прочитал статью о параллелизации в GO и ничего не понял – я тогда только начинал программировать на этом языке. Но размышления автора мне очень понравились – они подкреплялись бэнчмарками, что было довольно убедительно. Автор игрался c параметром GOMAXPROCS и показал, что увеличение этого параметра не всегда приводит к увеличению производительности. Под конец статьи он подобрал такое значение, которое будет максимально эффективным для его функции, на мое удивление, это значение оказалось равно единице! Т.е. его код работал максимально эффективно, если работал всего на одном ядре процессора! Однако, в одном из комментариев под той статьей я прочел, что все эти изыскания нелепы, поскольку та же самая функция из статьи запущенная всего в один поток оказывается эффективнее любой ее параллельной реализации.

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

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

Неотъемлемой частью дачи является система отопления. Конечно, существуют дачи, которые на зиму «консервируются», но в моем случае газовый котел и все коммуникации есть. Современные котлы оборудованы электронной управляющей платой. Изучив документацию на котел Lemax Primve обнаруживаем, что к плате подключаются несколько термисторов, датчик протока, реле давления воды, электрод ионизации, электрод розжига, в общем все, что нужно для его правильного функционирования. Старые чугунные котлы имели в своем распоряжении только горелку и биметаллическую пластину с газовым клапаном. Если пламя тухло по тем или иным причинам, нужно было свернуть старую газету, зажечь её кончик и внести в область горелки. С современными котлами такую процедуру проделывать категорически не рекомендуется. Лучше посмотреть код ошибки на экране или вызвать мастера.

Привет! Меня зовут Артур Нек, я Kanban-консультант и управляющий партнер Kaiten. Как руководителю, мне важно знать, как идут дела в проекте и есть ли какие-то проблемы. Постоянно спрашивать об этом у сотрудников в чатах или на почте неэффективно, а на просмотр досок и карточек проекта уйдет много времени.

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

Порой простое и очевидное решение может потянуть за собой хвост проблем в будущем. Например, добавление ретраев.

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

Этот пост — продолжение вымышленных историй о разработчике Васе, который несколько лет назад разбирался с идемпотентностью в распределённых системах. Теперь перед ним новые задачи — получится ли справиться с ними в этот раз? Давайте узнаем.

pub enum Expr<'src> {
  Int(u32)
  Ident(&'src str),
  // ...
}

Сегодня взял в руки книжку Эндрю Таненбаума "Архитектура компьютера" (последнее издание на русском языке вышло в 2018 году). Я ее пролистывал лет 10 назад, но сегодня решил пролистать снова, чтобы быть абсолютно уверенным в том что я напишу ниже. А именно: это книжка была вредна для образования. Она плодила не инженеров-проектировщиков, а потенциальных игроков для телевикторины "Что-Где-Когда?" и спорщиков-всезнаек на форумах интернета, которые могли рассуждать часами о микрокоде и джава-процессорах, нагибая собеседников своей эрудицией про очереди микроопераций (стр 291 4-го издания 2003-го года) и защелках в трактах данных (стр. 286), но при этом ничего не могли сделать своими руками.

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

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

На Хабре, как и вообще в русскоязычном сегменте Интернета, в‑основном можно найти обзорные статьи, дающие лишь общее представление о Юникоде, но о том, как с ним работать — информации крайне мало. Сами же его разработчики, Unicode Consortium, предоставляют довольно подробную… но очень объемную документацию, которую при этом мало просто прочитать — для полного понимания много чего в ней стоит прокодить.

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

Доброго времени суток, дорогие читатели!
В данной статье я буду рассказывать про холодную и горячую последовательность на примере такой задачи:
Пользователь заходит на сайт и начинается внутренняя прослушка (какой либо запрос на сервер с получением данных, в нашем же случае будет обычный sleepAsync - функция с таймаутом и остается только его подхватить и обработать). Режимов прослушки два - оптимизированный (будем называть горячим) и константный (будем называть холодным). При условии активности пользователя на вкладке, включаем оптимизированный метод, если же пользователь покинул вкладку, включаем константный. Также нужно показывать количество времени, которое занимала прослушка.

16 лет назад / 04 июля 2007 10:43

Какой хотелось бы видеть «идеальную» ОС? Чего такого хотелось бы иметь в «идеальной» операционной системе, чего нет или сильно ограничено в нынешних ОС?Например:

1.Хотелось бы чтобы ОС быстро реагировала на клавиатурные действия пользователя.

2. Хотелось бы чтобы перерисовка окон происходила независимо от прочих действий программы (то есть без подвисаний).

3. Хотелось бы чтобы переключение с программ вроде DirectX'овских происходило бысто и с первого раза; и чтобы переключение программ (например по Alt+Tab) вообще не зависело от желания текущей программы, что иногда наблюдается.

4. ...

Какой хотелось бы видеть «идеальную» ОС?

Другими словами, чтобы ничего не глючило и не тормозило!

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

Статья может вызвать неоднозначные впечатления, поэтому просьба сразу писать, в чем автор ошибся, и как надо сделать правильно!

В моей первой статье на хабре речь пойдет о комбинации примитивных конструкций, позволяющих организовать наследование реализаций и композицию состояний. Поочередно разберу, от простых в использовании конструкций, до комплексных prod-ready решений, которые могут найти повсеместного применения в разработке и публичных контейнерах. Здесь не будет зависимостей, макросов, Rc, Box и тд. - исключительноno_std.

Привет, меня зовут Емельянов Михаил, я Python-программист и я хотел бы показать вам свой небольшой «проект выходного дня» — Flywheel, микро-платформу для изучения иностранных языков — смесь Duolingo и Anki, программу, которая может помочь вам правильно писать на английском. Flywheel доступен в исходниках, лежит на GitHub.

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

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