Rose debug info
---------------

Богдан Стефанюк

Заметки о программировании, путешествиях и плёнке.
Обо мне  •  Список заметок  •  Плёнка  •  Война в Украине

Kindle

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

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

Что мне понравилось в Kindle? Небольшой размер, думал купить большую читалку, но понял что маленький размер намного оптимальнее. Ее удобно держать одной рукой и при этом она не устаёт. Также она помещается в карманы куртки или в бананке.

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

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

На днях амазон анонсировал что будет уходить от mobi в сторону epub, но я пока не пробовал как оно работает. Обновление еще не пришло.

В общем электронная книга это крутая альтернатива тупежу в телефон. С ней реально хочется больше читать.

Транзакции в базах данных и ACID

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

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

ACID гарантирует что данные в БД будут целостные независимо от любых сбоев.

Всего есть четыре свойства у транзакций:

  • Atomicity (атомарность) — команды внутри транзакции буду выполнены все вместе или ни одной. То есть транзакция это атомарная команда. Достигается это за счет системы откатов и журнала транзакций. Если внутри транзакции какой-то запрос выполнился с ошибкой, то все изменения, сделанные в рамках этой транзакции откатываются.
  • Сonsistency (консистентность) — данные должны быть консистентными после выполнения транзакции. Это значит что в них нету логических и технических противоречий. Например: суммарный баланс счетов должен оставаться неизменным, это логическая целостность. Записи в таблицах не ссылаются на удаленные идентификаторы в другой таблице — техническая целостность.
  • Isolation (изолированность) — транзакции зачастую обрабатываются параллельно, это значит что они не должны влиять друг на друга. Так если два человека одновременно пересылают деньги третьему, то одна транзакция может переписать данные другой и деньги потеряются. На практике изоляция достигается за счет уровней изоляции.
  • Durability (стойкость) — если транзакция завершена успешно, то она не может быть отменена даже при авариях, внезапном отключении света в датацентре и проблем в сети. В этом случае база данных должна сама восстановить последние изменения.

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

  • read uncommited — позволяет избежать потерянных обновлений, когда две транзакции изменяют одни и те же данные. Для этого одна транзакция блокирует данные, которые хочет изменить для других UPDATE операций в других транзакциях.
  • read committed — решает проблему грязного чтения, когда вычитываем данные во время их обновления. Это может привести к тому что мы получим частично обновленные данные. В таком случае UPDATE операции в транзакции блокируют UPDATE и SELECT операции в других транзакциях. Именно этот уровень изоляции используется по умолчанию в большинстве БД.
  • repeatable read — внутри транзакции может быть несколько операций SELECT, которые читают одни и те же данные. Repeatable read гарантирует что это операции внутри одной транзакции будут возвращать одинаковые данные. Даже если другие транзакции хотят их удалить или изменить. В таком случает транзакция блокирует все строчки, которые затрагивают операции UPDATE и SELECT.
  • serializable — исключает проблему «фантомных чтений», которые возникают при вставке новой строки между двумя операциями SELECT внутри одной транзакции. Больше всего эта проблема влияет на агрегационные запросы. Такой уровень изоляции является самым строгим, все транзакции выполняются так, будто других параллельных транзакций не существует.

Folder by Type и Folder by Feature

ASP.NET, как и большинство других фреймворков, предлагают использовать свою структуру организации файлов в проекте. Почти всегда используется folder by type подход. Он предполагает разделение файлов по типу. Так все контроллеры лежать в одной папке, вьюхи в другой и т. д.

com.example
├── Domain
│    ├── User.cs
│    └── Pet.cs
├── Controllers
│    ├── UserController.cs
│    └── PetController.cs
├── Repositories
│    ├── UserRepository.cs
│    └── PetRepository.cs
├── Services
│    ├── UserService.cs
│    └── PetService.cs
│   // and everything else in the project
└── Startup.cs

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

Альтернативой является folder by feature подход, при котором все файлы одной фичи лежат в отдельной папке. В таком случае все необходимое для конкретной фичи лежит под рукой и нет ничего лишнего.

Это позволяет:

  • Упростить навигацию в проекте.
  • Построить высокоуровневую абстракцию — открываешь проект и сразу понятно что он из себя представляет, из чего состоит.
  • Выделить вертикальные слои.
com.example
├── Pet
│    ├── Pet.cs
│    ├── PetController.cs
│    ├── PetRepository.cs
│    └── PetService.cs
├── User
│    ├── User.cs
│    ├── UserController.cs
│    ├── UserRepository.cs
│    └── UserService.cs
│   // and everything else in the project
└── Startup.cs

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

Ссылки:
Folder-by-type or Folder-by-feature

Интересные статьи

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

Choose Boring Technology — статья-презентация от одного из первых разработчиков Etsy. Рассказывает про выбор технологий для проекта. Основная идея в том чтобы выбирать «скучные», а если быть точнее, то хорошо изученные и устоявшиеся технологии. Горячо советую почитать.

Introduction to architecting systems for scale —
кратко о том из чего состоят приложения, которые рассчитаны для масштабирование.

Celebrate tiny learning milestones — не совсем техническая статья. Вместо того чтобы придумывать себе большие цели на год, лучше придумать набор небольших целей «майлстоунов» и идти по ним.

Get your work recognized: write a brag document — очень частая проблема это распознавание того что ты сделал на проекте. Когда приходит перформанс ревью, то бывает сложно вспомнить все что ты сделал за год. Автор советует завести документ в который нужно записывать результаты своей работы, а именно то, что было сделано и к чему это привело.

Good Logging — коротко о том какими должны быть логи чтобы ими было удобно пользоваться. Ну и сразу еще две статьи от этого же автора: Great Programmers Write Debuggable Code и Finding Bugs: Debugger versus Logging

Война в Украине

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

Но больше всего меня поражает та жестокость с которой ведаться эта война. Это война не за какую-то проведу или еще что-то. Это война на уничтожение. Война на уничтожение Украины. Страны в которой я вырос и в которой я живу. Которую я очень люблю.

Хочу обратиться к читателям с белоруссии и россии. Чтобы вам там не говорили по телевизору, здесь настоящая война, здесь настоящий ад на земле. И это дело рук ваших «доблестных» солдат. В первой версии этого поста я просил выйти вас на улицу, поднимать шум. Сейчас я понимаю что это бессмысленно. Часть вас просто боится, а второй части пофиг. Попрошу вторых забыть этот блог и никогда на него не заходить.

Ниже просто подборка фото и видео, напоминание об этой войне. О том что здесь происходит.

Победа будет за нами! Слава Україні!

Электронная музыка

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

Эта история началась в школьные годы, тогда я очень любил смотреть видео как люди делают музыку. Тогда же я познакомился с FL Studio. Скачал, открыл и непонимающе смотрел на все это. После начал читать какие-то гайды, но все свелось к тому что я просто сидел во всяких синтезаторах, крутил случайные лучки и слушал, что получается. Приблизительно в тоже время я познакомился с программированием, и оно затянуло меня по полной.

Потом я поступил в лицей, где познакомился с моим хорошим другом. Он тоже любил электронную музыку и также интересовался как ее делают. Часто смотрели всякие видосы о музыке, особенно доставляли те на которых ребята играют на «железках». Особенно удивил Launchpad от Novation.

Потом был универ, там я уже по полной влился в программирование, но желание делать музыку не покидало. Так что я как-то раз скачал Ableton и пробовал в нем что-то делать, но все равно далеко я не продвинулся.

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

Помещение школы
Учебный класс, на столе у каждого есть Ableton Push 2

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

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

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

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

Первое выступление

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

Постер выступления

Вначале не мог никак определиться с жанром, в котором буду писать. Начал с техно, не то чтобы часто его слушаю, так что фантазии не хватило написать что-то вменяемое. В итоге где-то две недели я просто ничего не делал и думал, что же написать. В какой-то момент чисто случайно вспомнил про один из любимых жанром: drum & bass.

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

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

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

Итог моего обучения можно послушать на саундклауде в виде записи моего выступления:

Железо

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

В общем, решил начать с малого и купить себе какой-то небольшой синт, в итоге остановился на Korg Volca Bass и не успел моргнуть, как скупил почти всю линейку Volca. И тут я понял, что сделал ошибку. Во-первых, за стоимость этих четырёх коробочек я мог взять один нормальный хороший синтезатор. Во-вторых, на изучение всего этого зоопарка просто не хватало времени и желания. Да и позже оказалось, что они мне не сильно нравятся, потому что неудобные.

Хорошо что я покупал их б/у и продал по той же цене, что и покупал. Решил приобрести одно устройство, над которым можно сконцентрироваться и хорошо изучить. Остановился на коробочках от Elektron. Меня подцепил красивый дизайн, удобство и мощный сэквенсор.

Купил FM синтезатор Elektron Model:Cycles и потом докупил еще Model:Samples. Получился достаточно сбалансированный сэтап, с ним я понял, что хочу делать. Но оказалось, что Model:Cycles не сильно подходит под мои задачи, а вот samples напротив очень понравился.

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

На эту тему есть просто шикарнейший доклад Максима Ильяхова — о демонах начинающих музыкантов и аналоговых синтах. После него я более спокойно стал относиться к железкам и сейчас они играют роль крутых игрушек для взрослых, с которыми приятно поиграть после работы или просто когда хочется отдохнуть от компьютера. Буду ли я покупать себе железо? Скорее всего, да. Если покупать б/у то можно неплохо сэкономить и потом продать за те же деньги. Оно не сделает меня крутым музыкантом, я просто люблю железо.

Семплы

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

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

Так что ограничения рулят. Об этом Сергей Король написал отличный пост: Самоограничения

Интересные доклады

Ну и напоследок поделюсь несколькими видео, которые мне очень сильно понравились и помогли в написании музыки:

Онлайн документация на базе WordPress и IdentityServer

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

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

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

Первым кандидатом был GitBook. У него приятный интерфейс, много опций по редактированию и оформлению текстов. Необходимый нам функционал также был, но доступен только в Enterprise версии. Цена оказалась слишком большой, пришлось искать дальше.

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

Wordpress

Оставался только один вариант — написать все самим, чего очень не хотелось делать. В какой-то момент я чисто случайно вспомнил про Wordpress. Не то что бы я им раньше пользовался, но много слышал о нем.

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

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

Весь функционал реализовали с помощью пачки плагинов. Главным среди них стал OAuth Single Sign On by miniOrange. Он позволяет логиниться в вордпесс с помощью сторонних сервисов (Google, Facebook и т. д.). Бесплатная версия покрывает почти все кейсы. На же пришлось покупать лицензию, потому что нужен был мапинг наших ролей на роли вордпреса.

За работу с пользователями в нашем приложении отвечает IdentityServer. Сделали отдельную страницу логина для SSO чтобы получить нужную куку. Также включили флаг AlwaysIncludeUserClaimsInIdToken в настройках клиента, чтобы клеймы ролей были в ID токене и их смог увидеть Wordpress.

Хостинг

С хостингом тоже все оказалось достаточно просто. Изначально хотели использовать AWS Lightsail, но основная проблема мы в отсутствии возможности перемещать снапшоты диска между аккаунтами. В итоге развернули все на EC2 с помощью готового бесплатного решения из AWS Marketplace.

Итого

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

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

Ну и стоимость порадовала. Все это обошлось в ~570$, в то время как типичный SaaS сервис берез 5$ в месяц за одного пользователя. Хостинг тоже вышел не очень дорогим (~10-15$ в месяц).

Где захостить свое приложение?

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

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

Типы сервисов

Для начала стоит кратко пройтись по моделям предоставления сервисов в облаке. Эти модели описывают зоны ответственности пользователя и облачного провайдера. В разрезе данной статьи нас интересуют следующие модели:

  • IaaS (Infrastructure as a Service) — облачный провайдер предоставляет минимально необходимую инфраструктуру в виде виртуальных машин, сети и хранилища, а также отвечает за работоспособность. Дальнейшая настройка, в том числе и ОС, лежит на стороне пользователя. По сути это основные строительные блоки в облаке с помощью которых можно сделать все что захотим.
  • PaaS (Platform as a Service) представляет из себя готовую инфраструктуру для разработки и запуска приложений. При такой модели мы не думаем про настройку и управление серверами, операционными системами и т. д. Примером такого сервиса являются управляемые БД (managed databases). Облачный провайдер сам отвечает за правильную настройку сервера, ОС, сохранность данных, бекапах и бесперебойную работу. В основном пользователь только платит деньги и пользуется сервисом.
  • Serverless, самая свежая модель, которая очень похожа на PaaS. Только при такой модели облако само выделяет ресурсы на основании текущей нагрузки. Все настройки и планирование ресурсов скрыто от пользователя. Ему остается только загрузить свой код, а все остальное сделает облако. Также в serverless мире обычно оперируют понятием облачная функция это код, который умеет обрабатывать только одни конкретный запрос.
Наглядный пример зон ответственности в разных моделях предоставления сервисов.

Где захостить .NET бекенд?

AWS/Azure/GCP

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

Больше всего нас интересую сервисы:

  • AWS EC2 (IaaS) обычные виртуальные машины. Есть маркетплейс на котором можно найти огромное множество готовых AMI образов с предустановленным софтом и нужными настройками. Например можно в один клик развернуть виртуалку с Wordpress и всем необходимым.
  • Azure App Service (PaaS) самый простой и нативный способ захостить .NET приложения. App Service сам разворачивает приложение из репозитория, настраивает все необходимое для работы и предоставляет полезные метрики.
  • AWS Lightsail (IaaS/PaaS) упрощенная версия AWS для тех кто с ним не знаком. Можно очень дешево арендовать виртуальную машину, поднять докер контейнер, развернуть БД и хранилище для файлов. Все это делается буквально в пару кликов мышкой. Первые три месяца бесплатные.
  • AWS Elastic Beanstalk (PaaS) умеет поднимать необходимые для работы приложения компоненты в AWS. По сути мы можем все это сделать руками, но Beanstalk автоматизирует всю рутину. Под капотом он представляет из себя набор разных CloudFormation скриптов, которые поднимают необходимые сервисы и настраивают их.

DigitalOcean

Самый простой в использовании сервис. Раньше в DO можно было арендовать только виртуальные машины, сейчас же можно создавать управляемы БД, балансировщики и т. д. На текущий момент почти все мои проекты крутяться в DigitalOcean.

Нам интересны следующие сервисы:

  • Droplets — виртуальная машина, есть много готовых образов на маркетплейсе под любой рантайм.
  • App Platform — позволяет нативно запускать приложения написанные на Python, Nodejs, Go, php или любое другое приложение в виде контейнера.

Heroku

Честно говоря я им ни разу не пользовался, но друзья очень часто советуют. Из коробки не поддерживает .NET приложения, но вроде как есть кастомные билд паки. В основном хероку позволяет развернуть приложения на Nodejs, Go, Python и т. д. Из приятных фишек: достаточно запушить код в репозиторий, все остальное сделает Heroku.

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

Где захостить фронтенд?

С фронтендом дела обстоят намного проще, есть огромное количество сервисов, которые позволяют бесплатно захостить фронт.

Мой личный фаворит — Vercel. Бесплатный план включает такие фишки как HTTPS, автоматически деплой с репозитория, собственный домен. Также он умеет разворачивать приложение под каждый PR, что позволяет протестировать изменения до того как влить код в основную ветку.

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

App Platform от Digital Ocean я уже упоминал выше. Можно поднять три статических сайта бесплатно, последующие за 3$ в месяц. Есть автоматический деплой, бесплатный HTTPS, возможность подключения своего домена. Сейчас в нем крутиться мое онлайн резюме. Сервис прикольный тем что в нем можно запустить и бек и фронт.

Последним хочу отметить AWS S3. По сути это объектное хранилище (хранилище для файлов) в котором есть встроенная поддержка сайтов. Для этого нужно загрузить HTML/CSS/JS файлы и включить соответствующую опцию в настройках бакета. Часто встречает в продакшене связку CloudFront + S3.

Где развернуть базу данных?

С базами данных ситуация сложнее, в основном предлагают развернуть БД за большие деньги. Такой вариант не подходит если мы хотим захостить небольшое приложение или просто его потестировать без установки БД локально. Вот несколько из вариантов:

  • ElephantSQL, можно развернуть PostreSQL базу данных любого размера. Бесплатный план дает базу с 20 Мб и 5 параллельными подключениями.
  • Mongo Atlas подойдет если нужно развернуть кластер MongoDB. Есть достаточно жирный бесплатный план.
  • В DigitalOcean и AWS Lightsail начиная с 15 долларов в месяц можно развернуть достаточно неплохой сервер БД, который не нужно настраивать и работает из коробки. В Lightsail первые 3 месяца бесплатно.

Полезные ссылки

Pentax 6x7

Сегодня расскажу о своей первой среднеформатной камере — Pentax 6x7. Идея попробовать средний формат возникла где-то полтора года назад, с тех пор я время от времени заходил на OLX (сайт с объявлениями) и просматривал что там есть. Изначально я смотрел в сторону советских фотоаппаратов таких как Киев-60 и Киев-88. Однажды я чисто случайно наткнулся на объявление по продаже Pentax. Цена была вполне вменяема да и состояние вроде как хорошее. Попросил у продавца дополнительных фото и оказалось что камера в отличном состоянии. Решил что стоит взять.

Впервые камера была представлена в 1969 компанией Asahi Pentax и производилась до 2000-х. Главная особенность камеры — форм-фактор, по сути это сильно увеличенная 35 мм камера. Но Pentax не является первой камерой в таком форма-факторе. С середины 1950-х годов в Германии выпускались камеры Pentacon Six.

Камеры выпускались в трех модификациях: Pentax 6x7 (мой экземпляр), Pentax 67 с добавленной функцией приподнятия зеркала и Pentax 67II. Последняя версия стала легче за счет добавления пластиковых деталей. Также в нее добавили экран и кнопки, которые позволяют настраивать камеру. Но и цена за нее в среднем в два раза больше предыдущего поколения.

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

Из других особенностей можно отметить:

  • Камера не является полностью механической. Спуском управляет небольшой механизм, который питается от батареек 4SR44.
  • Камера имеет встроенный в пентапризму экспонометр, который соединен с телом камеры с помощью цепного механизма, который легко повредить. Поэтому при разборе камеры нужно сначала снять объектив и только потом пентапризму.
  • Звук зеркала при спуске очень громкий, иногда люди оглядываются по сторонам.
  • Большое зеркало также порождает большую вибрацию, которая мешает делать кадры на выдержках длиннее 1/60.

Веб аналитика на коленке с помощью AWS

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

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

Это не какая-то уникальная проблема, обычно для таких задач берут Google Tag Manager. Но никто из нас не умел им пользоваться да и желания изучать особо не было.

И тут внезапно пришла идея как это сделать. Можно взять AWS Lambda, набросать на коленке пару строк кода, которые будут получать событие и куда-то их складывать для дальнейшего анализа. Для места хранения метрик выбрал CloudWatch. Он как раз умеет анализировать разные метрики/логи и строить красивые дашборды.

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

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

Актуальная аналитика

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

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

Ранее Ctrl + ↓