User
class User < ApplicationRecord
attr_accessor :remember_token
before_save { self.email = email.downcase }
validates :name, presence: true, length: { maximum: 50 }
VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
validates :email, presence: true, length: { maximum: 255 },
format: { with: VALID_EMAIL_REGEX },
uniqueness: { case_sensitive: false }
has_secure_password
validates :password, presence: true, length: { minimum: 6 }
# …далее ещё 30 строчек...
end
SOLID критикует тот, кто думает, что действительно понимает ООП
© Куряшкин Виктор
Я знаком с принципами SOLID уже 6 лет, но только в последний год осознал, что они означают. В этой статье я дам простое объяснение этим принципам. Расскажу о минимальных требованиях к языку программирования для их реализации. Дам ссылки на материалы, которые помогли мне разобраться.
Представляем вашему вниманию очередную порцию лекций Техносферы. На курсе изучается использование нейросетевых алгоритмов в различных отраслях, а также отрабатываются все изученные методы на практических задачах. Вы познакомитесь как с классическими, так и с недавно предложенными, но уже зарекомендовавшими себя нейросетевыми алгоритмами. Так как курс ориентирован на практику, вы получите опыт реализации классификаторов изображений, системы переноса стиля и генерации изображений при помощи GAN. Вы научитесь реализовать нейронные сети как с нуля, так и на основе библиотеке PyTorch. Узнаете, как сделать своего чат-бота, как обучать нейросеть играть в компьютерную игру и генерировать человеческие лица. Вы также получите опыт чтения научных статей и самостоятельного проведения научного исследования.
Когда-то я вылез из песочницы с совочком в руке и постом о неблокирующих очередях и передаче данных между потоками. Тот пост был не столько об алгоритмах и их реализации, сколько об измерении быстродействия. Тогда же мне в комментариях задали совершенно резонный вопрос об обычных, блокирующих алгоритмах передачи — насколько они медленнее и вообще как выбрать оптимальный алгоритм под конкретную задачу.
Пробежался по хабам и не нашел ничего написанного одновременно в хабы "D" и "Ненормальное программирование". Может сложиться совершенно ложное представление что на D пишут исключительно нормальные люди, или еще хуже того — что знание D автоматически делает из любого программиста нормального человека. Спешу опровергнуть.
Хотя сам я строго говоря программистом на D не являюсь — у меня нет ни одного промышленного проекта, зато я периодически с удовольствием роюсь в чужом коде выковыривая вкусные изюминки. А еще я пишу для себя небольшие утилиты, чаще всего для обработки текстовых данных, то что обычно делается на скриптовых языках, благо D предлагает очень неслабый набор инструментов для работы со строками.
Ну а там где текстовые процессоры, там и регулярные выражения, как же без них. И здесь D снова оказывается на высоте, по легкости и удобству использования его библиотека регулярных выражений приближается к Perl. Но в Perl регулярки являются частью синтаксиса, можно сказать что сам язык выстроен в значительной мере вокруг них, а в D это вполне себе независимый модуль — std.regex из стандартной библиотеки написанный Дмитрием Ольшанским. Еще один замечательный момент — парсер выражения может быть построен во время компиляции (естественно если само выражение задано литералом), и разумеется я не мог удержаться чтобы не посмотреть как оно внутри устроено.
И вот тут то, разбираясь в деталях у меня слетела шляпа возникла мысль, а нельзя ли вызывать одно регулярное выражение изнутри другого? Не вставить литерал (как тривиально можно сделать в Perl например), а непосредственно вызвать скомпилированный код одного выражения изнутри другого. Достаточно на мой взгляд дурацкая идея чтобы с ней стоило поиграть.
Итак, чего мы хотим? Примерно вот такого (пока это псевдокод):
INT=regexp("\d+");
LIST=regexp("INT(,INT)*");
Всем привет! Ко мне через личку обратились товарищи, сказав что, они не хотят комментировать, то что не поняли или поняли не до конца и попросили дать пояснения. На основе присланных вопросов я попытаюсь дать ответы в доступной форме.
Предыдущую статью восприняли лучше, чем я ожидал, так что решился на продолжение эксперимента. Это своеобразный ответ на перевод статьи Programming in D for C Programmers за авторством Дмитрия aka vintage. Как мне кажется, в области применения C Rust более уместен, чем замена Go, как предполагалось в прошлой статье. Тем интереснее будет сравнить. Опять таки, код на С приводить не буду, тем более что аналог на D всё равно смотрится лаконичнее.
