Для написания компьютерных программ и мобильных приложений используются строчки «кода», которые пишутся программистами. Сама по себе работа требует концентрации и аккуратности, поэтому ее удобно выполнять на ноутбуке, который можно взять с собой куда угодно.
1. Какой ноутбук выбрать программисту
Профессиональный программист «общается» с ноутбуком в течение всего дня, при этом у него загружен браузер с большим количеством вкладок, открыты виртуальная машина, несколько сред разработки и так далее. По этой причине лучше даже не смотреть в сторону ультрабюджетных и бюджетных моделей c TN-дисплеями и посредственными клавиатурами.
Что касается дисплея, это вопрос вкуса. 13- и 14-дюймовые варианты подходят для тех, кому важна компактность, но стоит иметь в виду, что подобные решения, как правило, не отличаются высокой производительностью, и процесс компиляции занимает много времени. С другой стороны, если приходится часто «собирать» код в приложение, то лучше обратить внимание на 15,6-дюймовые ноутбуки: именно в этом форм-факторе проще всего найти идеальное сочетание производительных компонентов.
2. Ноутбуки для работы с языками PHP, Python (web), MySQL, HTML, JS и CSS
В последнем случае не требуется hi-end ноутбук с 8-ядерным процессором, и в большинстве случаев вполне достаточно актуальных Intel Core i3 или AMD Ryzen 3, SSD-накопителя на 256 ГБ и 8 ГБ оперативной памяти. Это же применимо к программированию в PHP, HTML, JS и CSS.
Как выбрать правильный ноутбук для программирования
Выбор подходящего ноутбука для программирования может оказаться непростым.
В процессе данного выбора довольно легко запутаться в многообразии различных моделей,каждая из которых имеет свои плюсы и минусы.Написание кода возможно на большинстве ноутбуков,но ваша производительность улучшится, если вы будете использовать машину, подходящую для того типа задач, которые вы выполняете.
Существуют различные типы разработок, и для каждой специализации требуются различные инструменты. Таким образом, не существует универсального подхода к покупке машины для разработки.
В этой статье я сделал следующие предположения:
Вот некоторые соображения перед покупкой следующего ноутбука:
На данный момент существует огромное множества ноутбуков различных форм и размеров.И вы должны понимать насколько портативным должен быть ваш ноутбук.
Если большинство времени ваш ноутбук находиться дома, то скорее всего вам стоит рассматривать 15-дюймовые модели.Обычно такие ноутбуки имеют большие спецификации по сравнению с компактными аналогами, а также крупный экран, позволяющий без проблем работать с многозадачностью.
Но что делать если вам приходиться часто путешествовать или переезжать с одного места на другое?! Скорее всего в таких случаях подойдет 13-и или 14-и дюймовые машины.Они гораздо легче и имеют больший объем батареи.
Также вы могли задумываться о покупке ноутбука с тачскрином.Но я рекомендую вам избегать подобных устройств, так как они не имеют достаточное количество преимуществ, чтобы оправдать свою высокую цену.
Качество дисплея является одним из самых важных критериев при выборе ноутбука для программирования. Разработка приложений требует от вас долгое время проводить за экраном. Поэтому важно обращать внимание на все детали дисплея при его покупке
Большинство бюджетных ноутбуков поставляются с 1366 x 768 дисплеем,который я считаю в лучшем случае посредственным.На таком дисплее не хватает пространства для многозадачности. Кроме того, текст на этих экранах не достаточно четкий, чтобы вы могли комфортно читать.
4k дисплей для ноутбука является довольно бесполезной и избыточной функцией, особенно если учесть дополнительный разряд батареи с которым вы обязательно столкнетесь.
Что бы вы ни делали, не покупайте ноутбук с дисплеем менее Full HD 1920 x 1080 (1080p). Если вам нужно заплатить немного больше, чтобы получить 1080p, сделайте это.
Также убедитесь, что дисплей имеет хорошие углы обзора; экран вашего ноутбука не должен быть двойным, похожим на зеркало!
Процессор вашего ноутбука имеет огромное влияние на производительность, так что вы не должны позволять себе экономить на этом. Есть много различных типов процессоров с различными спецификациями. Самыми важными являются размер кэша, количество ядер, частота и тепловая мощность конструкции.
В общем, хорошего процессора Intel core i5 или i7 с частотой 3 ГГц и более должно хватить большинству людей.
Приобретение SSD (твердотельного накопителя) должно быть одним из ваших приоритетов. Это позволит вам значительно повысить производительность по сравнению со стандартным жестким диском. С SSD каждая операция будет выполняться намного быстрее: загрузка операционной системы, компиляция кода, запуск приложений и загрузка проектов.
Вы не в коем случае не должны идти на компромисс,выбирая ноутбук с недостаточно хорошим качеством клавиатуры. Так как ее вы будете использовать каждый день,печатая код.
Я обычно предпочитаю ноутбуки с более компактной раскладкой клавиатуры.
Емкость батареи может быть не столь важна для вас, если вы проводите большую часть времени рядом с розеткой. Тем не менее, лучше начинать по крайней мере с 6 часов работы от батареи.
Не рассчитывайте на заявленную производителем емкость батареи.Ознакомьтесь с оценками, полученными от третьих лиц на надежных веб-сайтах, и посмотрите, что реальные пользователи говорят о продукте на форумах и в обзорах.
Выбор операционной системы в значительной степени определят, покупку какого-либо ноутбука. У пользователей Windows есть множество вариантов, но если вы предпочитаете MacOS, вы ограничены предложениями Macbook.
Linux будет работать на большинстве ноутбуков, но лучше приобретать ноутбуки, которые имеют официальную поддержку Linux. Некоторые поставщики, такие как Dell и System 76, предоставляют высококачественные машины с предустановленной ОС Linux. Возможно, Вы захотите взглянуть на них в первую очередь.
В противном случае, проведите исследование, чтобы убедиться, что ноутбук, который Вы собираетесь купить, хорошо работает с предпочитаемыми Вами дистрибутивами Linux.
Дискретная видеокарта не очень важна для кодирования. Экономьте деньги, используя интегрированную видеокарту. Инвестируйте сэкономленные деньги в SSD или лучший процессор.
Еще больше полезной информации вы можете найти в нашем Телеграмм-канале по ссылке:
Как выбрать правильный лэптоп для программирования
Выбор лэптопа, подходящего для программирования – задача непростая.
Несложно запутаться, просматривая разнообразные варианты. Рынок предлагает много различных моделей, и каждая отличается определенным набором характеристик.
Писать код можно практически на любом лэптопе. Тем не менее, ваша продуктивность увеличится при использовании инструмента, наиболее подходящего под тип выполняемых задач.
Существуют разные типы разработки и для каждого из них есть свой инструмент. Таким образом, нет единого решения, подходящего всем одновременно.
При написании статьи я исходил из следующего:
Мобильность
Лэптоп можно подобрать любой формы и размера. Определитесь, насколько легким и портативным он должен быть.
Если вам не приходится часто передвигаться, то стоит обратить внимание на 15-дюймовые лэптопы. Они отличаются лучшими характеристиками и экранным пространством, достаточным для многозадачности.
Если вы работаете в нескольких местах или много путешествуете, то 13- или 14-дюймовые лэптопы — ваш выбор. Они более легкие, и батарея продержится дольше.
Если вы не покупаете лэптоп «два в одном», сенсорный экран не оправдывает дополнительные расходы на него. Я бы не рекомендовал приобретать лэптоп с сенсорным экраном.
Дисплей
Дисплей лэптопа — одна из наиболее важных его составляющих, особенно для программистов. Если вы занимаетесь разработкой, вы проводите перед экраном много времени. Вам необходимо уделять внимание деталям.
Разрешение экрана большинства бюджетных лэптопов — 1366 x 768, что на мой взгляд является весьма посредственным разрешением. Экранное пространство такого дисплея не достаточно для многозадачности. Ну и текст будет недостаточно четким для чтения.
С другой стороны, 4к дисплей — это слишком, особенно учитывая, что его наличие существенно увеличит как стоимость лэптопа, так и расход батареи.
В любом случае, не покупайте лэптоп с разрешением менее чем Full HD 1920 x 1080 (1080p). Если за разрешение 1080p надо немного доплатить — сделайте это.
Также убедитесь, что у дисплея достаточные углы обзора, экран не должен выполнять функции зеркала!
Процессор (CPU)
CPU лэптопа имеет огромное влияние на вашу производительность, так что не пытайтесь сэкономить на нем. Существуют различные типы процессоров с различными характеристиками, на которые следует обратить внимание. Наиболее значимыми характеристиками являются: объем кэш-памяти, количество ядер, частота и TDP (требования по теплоотводу).
В общем и целом, процессор Intel core i5 или i7 с частотой 3GHz и больше подойдет большинству.
ОЗУ (RAM)
Я не думаю, что можно серьезно заниматься программированием на лэптопе с ОЗУ менее, чем 4GB. Мои рекомендации по минимальному объему оперативной памяти — 8GB. И даже этого может оказаться недостаточно с появлением приложений Electron, которые используют большое количество ОЗУ. Если вы можете себе это позволить — инвестируйте в ОЗУ на 16GB.
Тип и объем памяти
Приобретение SSD должно практически стать вашим приоритетом номер один. Это даст вам значительное увеличение производительности по сравнению со стандартным жестким диском. Любая операция будет выполняться значительно быстрее с SSD, включая загрузку операционной системы, компиляцию кода, запуск приложений, загрузку проектов.
Рекомендуемый минимальный объем SSD — 256GB. Если у вас достаточно средств, то SSD на 512GB или 1TB — это лучший вариант. Если цена имеет значение, то приобретайте SSD с меньшим объемом, на котором будут находиться ваша операционная система, а также ваши приложения и наиболее часто используемые документы (такие как проектные файлы). Все остальное — например, музыка и видео — будет храниться на большем по объему жестком диске.
Клавиатура
Вы не можете позволить себе поступиться качеством клавиатуры, так как именно на ней вы будете днями и ночами набирать код. Я предпочитаю лэптопы с компактной клавиатурой.
Очень важно перед покупкой тщательно испытать клавиатуру. Убедитесь, что клавиши расположены удобно и их удобно нажимать. Клавиатура с подсветкой — полезная вещь, если вы планируете часто работать в плохо освещенных помещениях.
Питание
Хорошая батарея может не иметь для вас большого значения, если в основном вы находитесь недалеко от розетки. Тем не менее, вас должно интересовать время работы батареи от 6 часов и более.
Не рассчитывайте на время работы батареи, указанное производителем. Почитайте описания на достойных доверия веб-сайтах, посмотрите, что пишут реальные пользователи на форумах и в отзывах.
Операционная система
Выбор операционной системы в значительной степени определит то, какой лэптоп вы приобретете. Пользователям Windows доступен ряд вариантов, если же вы предпочитаете macOS, вы ограничены одним производителем.
Linux можно установить на большинство лэптопов, но лучше приобрести тот, который официально поддерживается Linux. Некоторые поставщики, такие как Dell and System 76, предлагают высококачественную продукцию с предустановленной ОС Linux. Рекомендую в первую очередь обратить внимание на эти варианты.
В ином случае проведите свое исследование, чтобы убедиться, что выбранный вами лэптоп хорошо сочетается с вашим предпочитаемым дистрибутивом Linux.
Дискретная или интегрированная видеокарта?
Наличие дискретной видеокарты не играет большой роли для написания кода. Купите лэптоп со встроенной видеокартой, а сэкономленные деньги потратьте на SSD или лучший процессор.
Интересно узнать, какие факторы вы считаете наиболее важными при выборе лэптопа для программирования и каким образом это влияет на вашу ежедневную работу. Делитесь в комментариях!
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией приложений, игр и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов, перевод технических текстов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
💻 30 лучших ноутбуков для программиста в 2020 году
Минимальные требования к ноутбуку:
Все остальные параметры меняются в зависимости от категории:
В описании ЦП в скобках указана частота в режиме турбобуста. В описании ОЗУ в скобках указан максимальный объем памяти, который можно установить в ноутбук при апгрейде.
1. До 30 000 ₽
Для чего: офисные программы, серфинг, просмотр видео. В этой категории выбирать почти не из чего – листайте дальше.
Большинство видов программирования не требует топового «железа», поэтому лэптопы из категории «от 30 000 до 50 000 ₽»будутоптимальным выбором. Надеемся, наш список поможет вам определиться с ноутбуком.
А теперь немного картинок, чтобы не быть голословным. Запускаю машину. Ubuntu 18.04 ест чуть меньше 1 гигабайта памяти.
Запускаю VS Code, стартую локальный сервер и открываю текущий свой проект в Google Chrome. Машина потребляет 2.2 гигабайта памяти.
Открываю свои привычные инструменты в браузере: помодоро таймер, web клиент телеграм, три вкладки stackoverflow, три вкладки документации Python, три вкладки документации Django и вкладка с YouTube. Также запустил нативный клиент Telegram. Машина ест 3 гигабайта оперативки и немного залезла в SWAP.
P.S. На Windows системе через WSL моя тачка работает почти на пределе, но всё ещё сносно. В нативной среде работать, всё же, приятнее.
Программирование на python
216 постов 7.5K подписчиков
Правила сообщества
Публиковать могут пользователи с любым рейтингом. Однако!
• уважение к читателям и авторам
• простота и информативность повествования
• тег python2 или python3, если актуально
• код публиковать в виде цитаты, либо ссылкой на специализированный сайт
• допускать оскорбления и провокации
• распространять вредоносное ПО
• просить решить вашу полноценную задачу за вас
Открой 5 сред разработки, нагугли 50+ вкладок, подними пару ssh тоннелей, открой зум, рокет чат, телеграм, запусти большой проект ноды в дев режиме, включи все линтеры, не забудь запустить второй браузер, чтобы наблюдать как в нем поехала верстка.
Добро пожаловать в веб разработку.
К сожалению, под PyCharm (и другими ему подобными IDE) такой сетап умрёт.
с такими запросами и характеристиками можно и на Raspberry Pi 4B учиться/работать. То же самое. 🙂 Кстати, на пи все довольно живенько работает, а на той что 64бит и 8Гб так вообще.
Но я все равно работаю на маке i9/16Gb ))
Оперативки много не бывает. У нас все Python и Go разработчики минимум с 12Гб сидят. И видюха чтобы пару мониторов 4к тянула и встроенный моник на ноуте.
4 гб памяти это дно, тем более для более-менее современного процессора.
Ко мне периодически приходят мученики и взывают к срочной и дорогой покупке нового компьютера, потому что старый начал тормозить. Потом старый приходит ко мне и всегда происходит один и тот же танец: из системы охлаждения вынимается полтора кота шерсти и пыли, дырявые термопрокладки меняются на медные пластинки, наносится новая термопаста, и вдруг машина начинает нормально работать. Дальнейший апгрейд сводится к добавлению памяти и замены жёсткого диска ссдшкой, и машина будет исправно служить ещё лет десять.
На такой системе работать практически нереально, сплошное мучение.
Скриншот в конце рабочего дня. Пара ssh туннелей, запущен маленький сервис, pycharm, браузеры, postman, пара консолей, spotify
На 14 дюймовом экране мне вполне удобно работать
Кстати, здорово развивает память) А виртуальные рабочие столы уже даже в винды завезли.
Но видно, что при нехватке оперативы уже начинает своп использоваться, сжатие и т.п.
А так, macOS очень агрессивно кеширует файлы в RAM и видно на первом фото что кешированные файлы почти всё оставшееся свободное место занимают.
Запущенные программы примерно такие: Xcode, Safari c 10-15 вкладками, мессенджеры (teams, telegram, slack), Postman, Figma.
P.S. Я iOS разработчик
Ну хз. у меня 12 горшков в проце и 64Гб оперативы. Вполне норм.
Как на самом деле работает заимствование чужого кода.
Не украл, а вдохновился архитектурой кода
Ответ на пост «Мыльная опера про программистов»
Когда учились в школе, у нас была информатика, мы там писали простенькие программки на бейсике. Я всё легко понимала, и писала программы на уроке одной из первых, обычно вторая, после одного парня, иногда третья, после 2х парней, и препод мне никогда не верил, что я сама написала, говорил, что я списала у тех двух, или они мне помогали. Я особо и не пыталась его убедить, как-то пофиг было. В итоге на финальном зачете, он спрашивает меня по теории, про циклы, условия, я всё отвечаю, он мне говорит, как сейчас помню:» Ты ведь ничего этого не понимаешь? Просто зазубрила, да?» Я конечно отвечаю, что всё понимаю. Я вообще думаю, что тут понимать? Циклы, условия-тут всё элементарно, как это можно вообще не понимать? Он так и не поверил, что я всё понимаю легко. Вот такие вот стереотипы. Уверена, что он так думал, потому что я девушка. Наверное он думал, что девушки не могут программировать. Но для меня это было самым легким и интересным из предметов, ну еще и математика. Поэтому пошла учиться на программиста. Вот бы он наверное удивился, узнав, что я отучилась в универе на программиста, и теперь работаю им же, при чем в универе из всего потока в 50 человек, писали программы от силы человек 7, и я в их числе, а остальные не могли или не хотели, списывали у других. По профессии мало кто пошел работать, даже среди тех, кто писал программы сам. Одна из нас ушла на службу по контракту, другой работает бортпроводником, про одного знаю, что работает программистом в Германии, но он был самый сильный на потоке. А насчет того парня, который в школе писал программы первым, нашла его лет 5 назад в контакте, работает в Макдональдсе в Питере, не знаю, на кого учился, но скорее всего по профессии работать не стал.
Ответ на пост «Ну, ошибся немного»
Вот уже на протяжении нескольких лет Тимофей, преподаватель кафедры информатики МФТИ, выкладывает свои лекции по программированию на своём Youtube канале с открытым доступом.
Не заметил подвоха
Требовательный код
Заказчик: ваш код требует слишком много памяти
Програмист: сейчас я вам покажу, что такое много памяти
Разработка системы заметок с нуля. Часть 2: REST API для RESTful API Service + JWT + Swagger
Продолжаем серию материалов про создание системы заметок. В этой части мы спроектируем и разработаем RESTful API Service на Go cо Swagger и авторизацией. Будет много кода, ещё больше рефакторинга и даже немного интеграционных тестов.
В первой части мы спроектировали систему и посмотрели, какие сервисы требуются для построения микросервисной архитектуры.
Подробности в видео и текстовой расшифровке под ним.
Начнём с макетов интерфейса. Нам нужно понять, какие ручки будут у нашего API и какой состав данных он должен отдавать. Макеты мы будем делать, чтобы понять, какие сущности, поля и эндпоинты нам нужны. Используем для этого онлайн-сервис NinjaMock. Он подходит, если макет надо сделать быстро и без лишних действий.
Страницу регистрации сделаем простую, с четырьмя полями: Name, Email, Password и Repeat Password. Лейблы делать не будем, обойдемся плейсходерами. Авторизацию сделаем по юзернейму и паролю.
После входа в приложение пользователь увидит список заметок, который будет выглядеть примерно так:
Интерфейс, который будет у нашего веб-приложения:
— Слева — список категорий любой вложенности.
— Справа — список заметок в виде карточек, который делится на два списка: прикреплённые и обычные карточки.
— Каждая карточка состоит из заголовка, который урезается, если он очень длинный.
— Справа указано, сколько секунд/минут/часов/дней назад была создана заметка.
— Тело заголовка — отрендеренный Markdown.
— Панель инструментов. Через неё можно изменить цвет, прикрепить или удалить заметку.
Тут важно отметить, что файлы заметки мы не отображаем и не будем запрашивать у API для списка заметок.
Полная карточка открывается по клику на заметку. Тут можно сразу отобразить полностью длинный заголовок. Высота заметки зависит от количества текста. Для файлов появляется отдельная секция. Мы их будем получать отдельным асинхронным запросом, который не помешает пользователю редактировать заметку. Файлы можно скачать по ссылке, также есть отдельная кнопка на добавление файлов.
Так будет выглядеть открытая заметка
В ходе прототипирования стало понятно, что в первой части мы забыли добавить еще один микросервис — TagsService. Он будет управлять тегами.
Для страниц авторизации и регистрации нам нужны эндпоинты аутентификации и регистрации соответственно. В качестве аутентификации и сессий пользователя мы будем использовать JWT. Что это такое и как работает, разберём чуть позднее. Пока просто запомните эти 3 буквы.
Для страницы списка заметок нам нужны эндпоинты /api/categories для получения древовидного списка категорий и /api/notes?category_id=? для получения списка заметок текущей категории. Перемещаясь по другим категориям, мы будем отдельно запрашивать заметки для выбранной категории, а на фронтенде сделаем кэш на клиенте. В ходе работы с заметками нам нужно уметь создавать новую категорию. Это будет метод POST на URL /api/categories. Также мы будем создавать новый тег при помощи метода POST на URL /api/tags.
Чтобы обновить заметку, используем метод PATCH на URL /api/notes/:uuid с измененными полями. Делаем PATCH, а не PUT, потому что PUT требует отправки всех полей сущности по спецификации HTTP, а PATCH как раз нужен для частичного обновления. Для отображения заметки нам ещё нужен эндпоинт /api/notes/:uuid/files с методами POST и GET. Также нам нужно скачивать файл, поэтому сделаем метод GET на URL /api/files/:uuid.
Структура репозитория системы
Ещё немного общей информации. Структура репозитория всей системы будет выглядеть следующим образом:
В директории app будет исходный код сервиса (если он будет). На уровне с app будут другие директории других продуктов, которые используются с этим сервисом, например, MongoDB или ELK. Продукты, которые будут использоваться на уровне всей системы, например, Consul, будут в отдельных директориях на уровне с сервисами.
Писать будем на Go
— Идём на официальный сайт.
— Копируем ссылку до архива, скачиваем, проверяем хеш-сумму.
— Распаковываем и добавляем в переменную PATH путь до бинарников Go
— Пишем небольшой тест проверки работоспособности, собираем бинарник и запускаем.
Установка завершена, всё работает
Теперь создаём проект. Структура стандартная:
— cmd — точка входа в приложение,
— internal — внутренняя бизнес-логика приложения,
— pkg — для кода, который можно переиспользовать из проекта в проект.
Я очень люблю логировать ход работы приложения, поэтому перенесу свою обёртку над логером logrus из другого проекта. Основная функция здесь Init, которая создает логер, папку logs и в ней файл all.log со всеми логами. Кроме файла логи будут выводиться в STDOUT. Также в пакете реализована поддержка логирования в разные файлы с разным уровнем логирования, но в текущем проекте мы это использовать не будем.
APIService будет работать на сокете. Создаём роутер, затем файл с сокетом и начинаем его слушать. Также мы хотим перехватывать от системы сигналы завершения работы. Например, если кто-то пошлёт приложению сигнал SIGHUP, приложение должно корректно завершиться, закрыв все текущие соединения и сессии. Хотел перехватывать все сигналы, но линтер предупреждает, что os.Kill и SIGSTOP перехватить не получится, поэтому их удаляем из этого списка.
Теперь давайте добавим сразу стандартный handler для метрик. Я его копирую в директорию pkg, далее добавляю в роутер. Все последующие роутеры будем добавлять так же.
Далее создаём точку входа в приложение. В директории cmd создаём директорию main, а в ней — файл app.go. В нём мы создаём функцию main, в которой инициализируем и создаём логер. Роутер создаём через ключевое слово defer, чтобы метод Init у роутера вызвался только тогда, когда завершится функция main. Таким образом можно выполнять очистку ресурсов, закрытие контекстов и отложенный запуск методов. Запускаем, проверяем логи и сокет, всё работает.
Но для разработки нам нужно запускать приложение на порту, а не на сокете. Поэтому давайте добавим запуск приложения на порту в наш роутер. Определять, как запускать приложение, мы будем с помощью конфига.
Создадим для приложения контекст. Сделаем его синглтоном при помощи механизма sync.Once. Пока что в нём будет только конфиг. Контекст в виде синглтона создаю исключительно в учебных целях, впоследствии он будет выпилен. В большинстве случаев синглтоны — необходимое зло, в нашем проекте они не нужны. Далее создаём конфиг. Это будет YAML-файл, который мы будем парсить в структуру.
В роутере мы вытаскиваем из контекста конфиг и на основании listen.type либо создаем сокет, либо вешаем приложение на порт. Код graceful shutdown выделяем в отдельный пакет и передаём на вход список сигналов и список интерфейсов io.Close, которые надо закрывать. Запускаем приложение и проверяем наш эндпоинт heartbeat. Всё работает. Давайте и конфиг сделаем синглтоном через механизм sync.Once, чтобы потом безболезненно удалить контекст, который создавался в учебных целях.
Теперь переходим к API. Создаём эндпоинты, полученные при анализе прототипов интерфейса. Тут важно отметить, что у нас все данные привязаны к пользователю. На первый взгляд, все ручки должны начинаться с пользователя и его идентификатора /api/users/:uuid. Но у нас будет авторизация, иначе любой пользователь сможет программно запросить заметки любого другого пользователя. Авторизацию можно сделать следующим образом: Basic Auth, Digest Auth, JSON Web Token, сессии и OAuth2. У всех способов есть свои плюсы и минусы. Для этого проекта мы возьмём JSON Web Token.
Работа с JSON Web Token
JSON Web Token (JWT) — это JSON-объект, который определён в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д., а также подписи (signature).
JWT использует преимущества подхода цифровой подписи JWS (Signature) и кодирования JWE (Encrypting). Подпись не даёт кому-то подделать токен без информации о секретном ключе, а кодирование защищает от прочтения данных третьими лицами. Давайте разберёмся, как они могут нам помочь для аутентификации и авторизации пользователя.
Аутентификация — процедура проверки подлинности. Мы проверяем, есть ли пользователь с полученной связкой логин-пароль в нашей системе.
Авторизация — предоставление пользователю прав на выполнение определённых действий, а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.
Другими словами, аутентификация проверяет легальность пользователя. Пользователь становится авторизированным, если может выполнять разрешённые действия.
Важно понимать, что использование JWT не скрывает и не маскирует данные автоматически. Причина использования JWT — проверка, что отправленные данные были действительно отправлены авторизованным источником. Данные внутри JWT закодированы и подписаны, но не зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных.
Реализация JWT в нашем APIService:
— Создаём директории middleware и jwt, а также файл jwt.go.
— Описываем кастомные UserClaims и сам middlware.
— Получаем заголовок Authorization, оттуда берём токен.
— Берём секрет из конфига.
— Создаём верификатор HMAC.
— Парсим и проверяем токен.
— Анмаршалим полученные данные в модель UserClaims.
— Проверяем, что токен валидный на текущий момент.
При любой ошибке отдаём ответ с кодом 401 Unauthorized. Если ошибок не было, в контекст сохраняем ID пользователя в параметр user_id, чтобы во всех хендлерах его можно было получить. Теперь надо этот токен сгенерировать. Это будет делать хендлер авторизации с методом POST и эндпоинтом /api/auth. Он получает входные данные в виде полей username и password, которые мы описываем отдельной структурой user. Здесь также будет взаимодействие с UserService, нам надо там искать пользователя по полученным данным. Если такой пользователь есть, то создаём для него UserClaims, в которых указываем все нужные для нас данные. Определяем время жизни токена при помощи переменной ExpiresAt — берём текущее время и добавляем 15 секунд. Билдим токен и отдаём в виде JSON в параметре token. Клиента к UserService у нас пока нет, поэтому делаем заглушку.
Добавим в хендлер с heartbeat еще один тестовый хендлер, чтобы проверить работу аутентификации. Пишем небольшой тест. Для этого используем инструмент sketch, встроенный в IDE. Делаем POST-запрос на /api/auth, получаем токен и подставляем его в следующий запрос. Получаем ответ от эндпоинта /api/heartbeat, по истечении 5 секунд мы начнём получать ошибку с кодом 401 Unauthorized.
Наш токен действителен очень ограниченное время. Сейчас это 15 секунд, а будет минут 30. Но этого всё равно мало. Когда токен протухнет, пользователю необходимо будет заново авторизовываться в системе. Это сделано для того, чтобы защитить пользовательские данные. Если злоумышленник украдет токен авторизации, который будет действовать очень большой промежуток времени или вообще бессрочно, то это будет провал.
Чтобы этого избежать, прикрутим refresh-токен. Он позволит пересоздать основной токен доступа без запроса данных авторизации пользователя. Такие токены живут очень долго или вообще бессрочно. После того как только старый JWT истекает мы больше не можем обратиться к API. Тогда отправляем refresh-токен. Нам приходит новая пара токена доступа и refresh-токена.
Хранить refresh-токены на сервере мы будем в кэше. В качестве реализации возьмём FreeCache. Я использую свою обёртку над кэшем из другого проекта, которая позволяет заменить реализацию FreeCache на любую другую, так как отдает интерфейс Repository с методами, которые никак не связаны с библиотекой.
Пока рассуждал про кэш, решил зарефакторить существующий код, чтобы было удобней прокидывать объекты без dependency injection и синглтонов. Обернул хендлеры и роутер в структуры. В хендлерах сделал интерфейс с методом Register, которые регистрируют его в роутере. Все объекты теперь инициализируются в main, весь роутер переехал в мейн. Старт приложения выделили в отдельную функцию также в main-файле. Теперь, если хендлеру нужен какой-то объект, я его просто буду добавлять в конструктор структуры хендлера, а инициализировать в main. Плюс появилась возможность прокидывать всем хендлерам свой логер. Это будет удобно когда надо будет добавлять поле trace_id от Zipkin в строчку лога.
Вернемся к refresh_token. Теперь при создании токена доступа создадим refresh_token и отдадим его вместе с основным. Сделаем обработку метода PUT для эндпоинта /api/auth, а в теле запроса будем ожидать параметр refresh_token, чтобы сгенерировать новую пару токена доступа и refresh-токена. Refresh-токен мы кладём в кэш в качестве ключа. Значением будет user_id, чтобы по нему можно было запросить данные пользователя у UserService и сгенерировать новый токен доступа. Refresh-токен одноразовый, поэтому сразу после получения токена из кэша удаляем его.
Для описания нашего API будем использовать спецификацию OpenAPI 3.0 и Swagger — YAML-файл, который описывает все схемы данных и все эндпоинты. По нему очень легко ориентироваться, у него приятный интерфейс. Но описывать вручную всё очень муторно, поэтому лучше генерировать его кодом.
— Создаём эндпоинты /api/auth с методами POST и PUT для получения токена по юзернейму и паролю и по Refresh-токену соответственно.
— Добавляем схемы объектов Token и User.
— Создаём эндпоинты /api/users с методом POST для регистрации нового пользователя. Для него создаём схему CreateUser.
Понимаем, что забыли сделать хендлер для регистрации пользователя. Создаём метод Signup у хенлера Auth и структуру newUser со всеми полями для регистрации. Генерацию JWT выделяем в отдельный метод, чтобы можно было его вызывать как в Auth, так и в Signup-хендлерах. У нас всё еще нет UserService, поэтому проставляем TODO. Нам надо будет провалидировать полученные данные от пользователя и потом отправить их в UserService, чтобы он уже создал пользователя и ответил нам об успехе. Далее вызываем функцию создания пары токена доступа и refresh-токена и отдаём с кодом 201.
У нас есть подсказка в виде Swagger-файла. На его основе создаём все нужные хендлеры. Там, где вызов микросервисов, будем проставлять комментарий с TODO.
Создаём хендлер для категорий, определяем URL в константах. Далее создаём структуры. Опираемся на Swagger-файл, который создали ранее. Далее создаём сам хендлер и реализуем метод Register, который регистрирует его в роутере. Затем создаём методы с логикой работы и сразу пишем тест API на этот метод. Проверяем, находим ошибки в сваггере. Таким образом мы создаём все методы по работе с категориями: получение и создание.
Далее создаём таким же образом хендлер для заметок. Понимаем, что забыли методы частичного обновления и удаления как для заметок, так и для категорий. Дописываем их в Swagger и реализуем методы в коде. Также обязательно тестируем Swagger в онлайн-редакторе.
Здесь надо обратить внимание на то, что методы создания сущности возвращают код ответа 201 и заголовок Location, в котором находится URL для получения сущности. Оттуда можно вытащить идентификатор созданной сущности.
В третьей части мы познакомимся с графовой базой данных Neo4j, а также будем работать над микросервисами CategoryService и APIService.
Рис. 5. Ноутбук Acer Aspire 3 A315-42
