Вы можете использовать это руководство для различных целей:

• Чтобы понять, что такое Spring Framework
• Как работают ее основные фичи: такие как внедрение зависимостей или Web MVC
• Это также исчерпывающий FAQ (Перечень часто задаваемых вопросов)

Примечание: Статья ~ 9000 слов, вероятно, не стоит читать ее на мобильном устройстве. Добавьте ее в закладки и вернитесь позже. И даже на компьютере ешь читай этого слона по одному кусочку за раз :-)

Содержание

• Введение
• Основы внедрения зависимостей
• Контейнер Spring IOC / Dependency Injection
• Spring AOP (Аспектно-ориентированное программирование) и прокси
• Управление ресурсами Spring
• Spring Web MVC
• Дополнительные модули Spring Framework
• Spring Framework: часто задаваемые вопросы
• Заключение

Вы можете использовать эту статью, чтобы понять, как использовать Spring MVC для создания веб-сайтов или RESTful сервисов. А также получить обзор часто задаваемых вопросов, охватывающих наиболее распространенные задачи Spring MVC.

Примечание: Статья ~ 7500 слов, вероятно, не стоит читать ее на мобильном устройстве. Добавьте ее в закладки и вернитесь позже.

Содержание

• Введение
• HttpServlets 101
• DispatcherServlet
• Контроллеры — создание HTML
• REST контроллеры — создание XML / JSON
• Часто задаваемые вопросы
• Заключение
• Благодарности

Рано или поздно это случается с каждой компанией: вам понадобится новая система видеонаблюдения. Это может быть система, которую вы устанавливаете впервые или облачный апгрейд уже существующих камер – в любом случае вам нужно сделать что-то для усиления контроля. И пока вас будут занимать функции и преимущества разных технологий, финансовую службу заинтересует вопрос возврата инвестиций.

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

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

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

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

Среди тем предстоящей конференции TechLead Conf 2020 будет детальное обсуждение Domain-Driven Design и EventStorming. Помимо подготовки 2-слотового доклада Константина Густова о DDD, доклада Сергея Баранова об EventStorming и митапа, во время которого мы будем создавать DDD-радар, мы решили перевести статью об одном из самых популярных способов проектирования bounded context.

Как разбить большую систему на мелкие более управляемые компоненты? Мне часто задают этот вопрос, поэтому я собрал свои знания в эту статью.

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

Начнем с переписки

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

I am pleased to hear from you

Это можно перевести как “Спасибо, что написали” или “Благодарю за обращение”.

We greatly appreciate your feedback

В русском фраза звучит как “Огромное спасибо за обратную связь”.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

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

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

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

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

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

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

Blockchain

Блокчейны – технология распределённых вычислениях и общем консенсусе пользователей, созданная таинственным Сатоши Накамото. В ней отсутствует центральное управление, а для верификации транзакций используются P2P-сети, кодификации и криптография. Более того, транзакциями можно управлять при помощи программируемых контрактов/договоров. В блокчейне Биткоина любые транзакции не считаются легитимными (подтверждёнными), пока информация о них не будет сгруппирована в специальные структуры — блоки. Структура и информация в блоках подчиняется заданным правилам и её можно быстро проверить. Каждый блок всегда содержит информацию об одном предыдущем блоке. Это позволяет все существующие блоки выстроить в одну цепочку, которая представляет собой распределённую базу данных и содержит информацию о всех совершённых когда-либо операциях с bitcoin.

Bitcoin – это первое и самое успешное применение технологии блокчейнов, но есть и многие, многие другие криптовалюты, известные как альткоины. Более того, есть много примеров того, как новые блокчейны используются не только для криптовалютных целей – Ethereum, Ripple и Storj.io, о них мы сегодня и поговорим в первой части нашего цикла статей про децентрализованные сервисы. В свете последних событий, целью статьи является также показать, что кролики это не только ценный мех Bitcoin это не только платежная система, а новая революционная технология, которая открывает целый ряд возможностей для построения принципиально новых программных продуктов.

Тем, кто знаком с криптографией с открытым ключом, наверно известны аббревиатуры ECC, ECDH и ECDSA. Первая — это сокращение от Elliptic Curve Cryptography (криптография на эллиптических кривых), остальные — это названия основанных на ней алгоритмов.

Сегодня криптосистемы на эллиптических кривых используются в TLS, PGP и SSH, важнейших технологиях, на которых базируются современный веб и мир ИТ. Я уже не говорю о Bitcoin и других криптовалютах.

До того, как ECC стала популярной, почти все алгоритмы с открытым ключом основывались на RSA, DSA и DH, альтернативных криптосистемах на основе модулярной арифметики. RSA и компания по-прежнему популярны, и часто используются вместе с ECC. Однако несмотря на то, что магия, лежащая в фундаменте RSA и подобных ей алгоритмов легко объяснима и понятна многим, а грубые реализации пишутся довольно просто, основы ECC всё ещё являются для большинства людей загадкой.

В этой серии статей я познакомлю вас с основами мира криптографии на эллиптических кривых. Моя цель — не создание полного и подробного руководства по ECC (в Интернете полно информации по этой теме), а простой обзор ECC и объяснение того, почему её считают безопасной. Я не буду тратить время на долгие математические доказательства или скучные подробности реализации. Также я представлю полезные примеры с визуальными интерактивными инструментами и скриптами.

Собаководы знают, какая это боль — оставить собаку во время отпуска или поездки. В мае 2016 в Москве запустился сервис по выгулу и догситтингу "Собака-гуляка", который собрал много положительных отзывов в СМИ.  
 
Проект Mishiko связывает с ребятами возможность долгого и доброго партнерства: с трекером владельцы собак могут зайти в приложение и узнать, что их собака в порядке на всё время передержки.
 
Чтобы узнать больше о том, как работает сервис Собаки-гуляки, мы лично встретились с одним из выгульщиков, а также пообщались с основателями сервиса. Расскажем всё из первых уст.


КДПВ с одним из выгульщиков Собаки-гуляки

Алексей Акулович объясняет жизненный путь высоконагруженного проекта на PHP. Это — расшифровка Highload ++ 2016.

Меня зовут Лёша, я пишу на PHP.

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

Начнём.

Привет, Хабр! Не так давно в издательстве «Manning» вышла непростая, но долгожданная и выстраданная автором книга о функциональном моделировании предметных областей.



Поскольку у нас готовятся книги как по Scala, так и по паттернам предметно-ориентированного проектирования, опубликуем одну из статей сахиба Гоша об идеях, заложенных в его книгу, и спросим, насколько эта книга была бы вам интересна

Петр Зайцев показывает разницу между MySQL и MongoDB. Это — расшифровка доклада с Highload++ 2016.

Если посмотреть такой известный DB-Engines Ranking, то можно увидеть, что в течении многих лет популярность open source баз данных растет, а коммерческих — постепенно снижается.

Введение

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

Событие, когда какая-то статья вызывает бурю эмоций, — крайне редкое. Первый раз такое возникло, когда я прочитал про chained replication. Меня пытались убедить, что это мощный подход и что это лучшее, что могло произойти с консистентной репликацией. Я сейчас не буду приводить доводы, почему это плохо работает, а просто приведу говорящую цитату из статьи Chain Replication metadata management:

Split brain management is a thorny problem. The method presented here is one based on pragmatics. If it doesn’t work, there isn’t a serious worry, because Machi’s first serious use case all require only AP Mode. If we end up falling back to “use Riak Ensemble” or “use ZooKeeper”, then perhaps that’s fine enough.

В моем вольном пересказе это означает примерно следующее: "У нас тут есть некий алгоритм. Мы не знаем, будет ли он работать правильно или нет. Да нам это и не важно". Хотя бы честно, сэкономило кучу времени, спасибо авторам.

И тут, значит, попадается на глаза статья: Spanner, TrueTime & The CAP Theorem. Её мы разберем по полочкам ближе к концу, вооружившись понятиями и знаниями. А перед этим разберем самые распространенные мифы, связанные с CAP теоремой.