Skip to content

Instantly share code, notes, and snippets.

Avatar
:octocat:
Enjoying private GitHub repos

Igor Minin Igogrek

:octocat:
Enjoying private GitHub repos
View GitHub Profile
@Igogrek
Igogrek / scooters.md
Last active Sep 23, 2020
Scooter monitoring
View scooters.md

Вернуть пропавший скутер, или история одного IoT мониторинга

Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.

Изначально проект назывался Road-To-Barcelona, позже стал Road-To-Berlin (отсюда встречающиеся на скриншотах R2B), а в итоге и вовсе был назван xRide.

Основная идея проекта была в следующем: вместо того чтобы иметь централизованный сервис проката автомобилей или скутеров (речь пойдет о скутерах aka электро-мотоциклах, а не kickscooter/самокатах) мы хотели сделать платформу для децентрализованной аренды. О сложностях с которыми мы столкнулись уже писали ранее.

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

@Igogrek
Igogrek / Go code conventions.md
Last active Sep 21, 2020
Our team Go code custom conventions
View Go code conventions.md

General conventions

Effective go

Our main source of code conventions is the standard GO conventions from effective go - see https://golang.org/doc/effective_go.html

Please try to follow them as much as possible.

Context

All of our apps should have a context. This means one struct with references to the underlying dependencies. No global variables should exist. Context should be manually initialized at the start of the service with cascading initialization of all the underlying dependencies hierarchically. Constructors should be used to pass the dependencies.

This approach is used in absence of a nice dependency injection mechanism, but it has it's own benefits too.

@Igogrek
Igogrek / How I started loving Vue.md
Last active Apr 10, 2020
How I started loving Vue
View How I started loving Vue.md

This article is the logical conclusion of my previous article - How I stopped loving Angular. Recommended to check before reading this one.

We have been using Vue instead of Angular for nearly a year now. In this article, I will highlight my impressions on Vue and differences compared to Angular.

Moreover, I will add some hands on experience notes from usage of Vue on real projects.

View Cookbook.md

This cookbook is similar to Vue cookbook but contains our custom recipes for some specific cases.

Form validation

For form validation we use Vuelidate

export default Vue.extend({
  ...
  validations: {
@Igogrek
Igogrek / Vue code style.md
Last active Jul 27, 2020
Code style and application structure
View Vue code style.md

Application structure

General

  1. Application has tree structure with folders for each "feature"
  2. Feature folders are named with lowerCamelCase → myComponentDashboard
  3. Feature can contain any number of components and nested features
  4. Components are named using UpperCamelCase → MyWidgetComponent.vue
  5. Component can have translation .yml file named correspondingly → MyWidgetComponent.yml
  6. If component requires more than 2 files: .vue and .yml file - folder is created with the same name → MyWidgetComponent
@Igogrek
Igogrek / Как я начал любить Vue.md
Last active Dec 27, 2020
Как я начал любить Vue
View Как я начал любить Vue.md

Вступление

Данный пост - это логическое продолжение моего поста/статьи - Как я перестал любить Angular / How I stopped loving Angular. Рекомендуется к ознакомлению перед прочтением.

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

@Igogrek
Igogrek / How I stopped loving Angular.md
Last active Jan 13, 2021
How I stopped loving Angular
View How I stopped loving Angular.md

I've worked with AngularJS for many years now and still use it in production today. Even though you can't call it ideal, given its historically-formed architecture, nobody would argue that it became quite a milestone not only for evolution of JS frameworks, but for the whole web.

It's 2017 and every new product/project has to choose a framework for development. For a long time I was sure that new Angular 2/4 (just Angular below) will become the main trend for enterprise development for years to come. I wasn't even thinking of working with something else.

Today I refuse to use it in my next project myself.

View Как я перестал любить Angular.md

Вступление

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

На дворе 2017ый год и для каждого нового продукта/проекта встает вопрос выбора фреймворка для разработки. Долгое время я был уверен, что новый Angular 2/4 (далее просто Angular) станет главным трендом enterprise разработки еще на несколько лет вперед и даже не сомневался что буду работать только с ним.

Сегодня я сам отказываюсь использовать его в своем следующем проекте.

Дисклеймер: данная статья строго субъективна, но таков мой личный взгляд на происходящее и касается разработки enterprise-level приложений.