Comments / Profile of tolyanski / Habr

Было и такое у меня, в 2018 году летел из Москвы в Гонконг с пересадкой в Абу-Даби. И на второй части маршрута попался огромный А380 от Etihad с интернетом на борту. Да, было ощущение цивилизации. Но прошло 7 лет с тех пор, и пока к сожалению интернет на борту так и остался только в Etihad и то вроде не на всех самолетах :(

-1

Look

В России падает спрос на ноутбуки при снижении цен

tolyanski Jun 7 at 12:18

Вы тоже ощущали это прекрасное чувство, что в самолёте ну вообще никто не достучится, да? :-)

Вообще кайф был, да))

Look

В России падает спрос на ноутбуки при снижении цен

tolyanski Jun 6 at 21:37

Скажите мне, люди, вы правда погромируете что-то в электричке, на пляже?

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

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

Про электрички: именно в электричке не было. Но было в Сапсане в вагоне-ресторане, а также в бесконечном количестве аэропортов в ожидании рейса.

А еще был такой случай. Был 9-часовой перелет в будний день прямо в рабочие часы. А у меня на этот день было запланировано разгрести кучу задач джунов по код-ревью. Перед вылетом я коллегам написал в чате: посоны, я буду без связи, но все ревью проведу, все будет ништяк. В самолете предусмотрительно выбрал место в ряду где можно спокойно вытянуть ноги и расположиться без какого-либо дискомфорта. Все задачи из git-репы выкачал себе на ноут, тексты задач в Джире тоже накопипастил в блокнотик. Сидя в самолете глядел код, комменты выписывал в заметки, а по прилету все вывалил на Gitlab.

Look

Стоит ли менять работу летом?

tolyanski Jun 4 at 14:54

На этапе проверки СБ уже вполне могут попросить выписку из трудовой, и на Госуслугах в пару кликов её можно сделать.

Ахаха, в стране где половина людей оформлены по ИП/ГПХ, либо оформлены заграницей, либо вчерную, либо зп криптой, а еще где у одной ИТ компании может быть миллион дочек, между которыми сотрудника могут переоформлять 10-15 раз за 2 года работы - удачи проверять в СБ достоверность резюме.

Смешной вы однако)

Look

Стоит ли менять работу летом?

tolyanski Jun 3 at 14:29

Любой работодатель как правило отдает предпочтение тем кандидатам, которые находятся на грани голодной смерти, и соответственно не могут себе позволить долгие каникулы. По мнению работодателей, такие ~~рабы~~ кандидаты более охотно и вовлеченно выполняют свою работу ~~и не выебываются~~.
Поэтому, перерывы в резюме лучше скрывать, независимо от причин, по которым эти перерывы случались.

Look

Стоит ли менять работу летом?

tolyanski Jun 2 at 22:56

Получилось очень похоже:

Стоит ли менять работу летом: за и против

Лето — традиционный период отпусков, отдыха и замедления деловой активности. Многие сотрудники стараются использовать это время для перезагрузки, отпусков с семьей и не спешат принимать судьбоносные решения. Однако вопрос «А стоит ли менять работу именно летом?» остаётся актуальным для тех, кто чувствует внутреннюю неудовлетворенность, желание профессионального роста или просто находится в поиске новых возможностей. Давайте рассмотрим плюсы и минусы смены работы в летний период.

Минусы смены работы летом

Меньше вакансий.
Лето — не самое активное время на рынке труда. Руководители и HR-менеджеры часто в отпусках, а компании временно «замораживают» активный подбор персонала. Это может привести к ощущению, что «рынок пустует», особенно в июне-июле.
Замедленные процессы.
Даже если подходящая вакансия есть, процесс найма может затянуться. Проведение собеседований, согласование решений и оформление документов могут происходить в более вялом темпе, что тормозит смену работы.
Риск упустить отпуск.
Если вы планировали отпуск на лето, смена работы может его отложить или вовсе отменить. Новому сотруднику редко дают отпуск сразу — придётся набрать «кредит доверия».

Плюсы смены работы летом

Меньше конкурентов.
Большинство соискателей решают отложить активный поиск до осени. Это значит, что ваши шансы привлечь внимание рекрутеров выше. На одну и ту же вакансию откликнется меньше людей, а значит — выше вероятность получить приглашение на интервью.
Больше внимания к кандидатам.
За счёт уменьшения потока резюме HR-специалисты могут уделить больше времени и внимания каждому кандидату. Это повышает шансы быть замеченным и оценённым по достоинству.
Время на адаптацию.
В летний период нагрузка в компаниях часто ниже, чем осенью или в начале года. Это даёт возможность новичку мягко войти в коллектив, освоиться с процессами и без стресса адаптироваться к новым задачам.

Когда стоит менять работу летом

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

Когда лучше повременить

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

Итог

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

Look

SOSAL: Современный социальный подход к программированию

tolyanski Jun 2 at 22:13

Логотипчик подвезли)

Look

Минфин РФ: многие уехавшие в 2022 году IT-специалисты вернулись обратно после введения льгот ипотеки для IT-компаний

tolyanski Jun 2 at 22:11

Желаю и Вам Успехов в изучении теории отношений и пусть они будут только взаимными.

И Вам :)

Look

tolyanski Jun 2 at 21:13

Что означает что успех мужчины в жизни во многом зависит от того, принимают ли его женщины или отвергают.

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

Я давно замечал, как женщины бывает обсуждают мужчин между собой и пытаются вспомнить/уточнить о каком именно мужчине идет речь. Чаще всего произносят в таком виде: "Я встретилась с Ваней, ну тот, который ресторатор" или "Помнишь Сашу? ну, айтишник" - то есть прибавляют род профессиональной деятельности, чтобы уточнить и дать понять что именно за мужчина.
Ну еще бывают варианты, когда в качестве уточнения говорят какая у него машина: "Ну помнишь Сергея? Белая такая машина, Мазда" ))

И это правильно! Миссия мужчины - генерировать ресурсы, необходимые для жизни. А миссия женщины - эту самую жизнь воспроизводить. Как бы мы ни "осуждали" женщин за их меркантильность, но именно с точки зрения природы/эволюции, все более чем логично и нормально.

Если тебя не выбрали - ничего тебе не поделать

Если тебя не выбрали - зарабатывай бабки, и тогда выберут)

Look

SOSAL: Современный социальный подход к программированию

tolyanski Jun 2 at 20:55

Конечно! Ниже — минимальное Go-приложение, следующее принципам ZASRAL. Это REST API, предоставляющее работу со списком задач (TODO list), написанное с соблюдением SOLID, минимальными багами (и тестами!), логичным делением ответственности, возможностью быстрой адаптации (Agility), и комментариями, указывающими на ретроспективные точки.

🧱 Структура проекта

zasral-todo/
├── main.go
├── handler/
│   └── todo_handler.go
├── service/
│   └── todo_service.go
├── model/
│   └── todo.go
├── repository/
│   └── memory_repo.go
└── test/
    └── todo_test.go

main.go

package main

import (
    "log"
    "net/http"
    "zasral-todo/handler"
    "zasral-todo/repository"
    "zasral-todo/service"
)

func main() {
    repo := repository.NewInMemoryRepo()
    srv := service.NewTodoService(repo)
    h := handler.NewTodoHandler(srv)

    http.HandleFunc("/todos", h.HandleTodos)

    log.Println("Server started on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

model/todo.go

package model

type Todo struct {
    ID   int    `json:"id"`
    Text string `json:"text"`
    Done bool   `json:"done"`
}

repository/memory_repo.go

package repository

import (
    "sync"
    "zasral-todo/model"
)

type InMemoryRepo struct {
    mu    sync.Mutex
    todos []model.Todo
    nextID int
}

func NewInMemoryRepo() *InMemoryRepo {
    return &InMemoryRepo{}
}

func (r *InMemoryRepo) Add(todo model.Todo) model.Todo {
    r.mu.Lock()
    defer r.mu.Unlock()
    todo.ID = r.nextID
    r.nextID++
    r.todos = append(r.todos, todo)
    return todo
}

func (r *InMemoryRepo) List() []model.Todo {
    r.mu.Lock()
    defer r.mu.Unlock()
    return append([]model.Todo(nil), r.todos...)
}

service/todo_service.go

package service

import "zasral-todo/model"

// Интерфейс для абстракции над хранилищем (D — Dependency Inversion)
type Repo interface {
    Add(todo model.Todo) model.Todo
    List() []model.Todo
}

type TodoService struct {
    repo Repo
}

func NewTodoService(r Repo) *TodoService {
    return &TodoService{repo: r}
}

func (s *TodoService) CreateTodo(text string) model.Todo {
    return s.repo.Add(model.Todo{Text: text})
}

func (s *TodoService) GetAll() []model.Todo {
    return s.repo.List()
}

handler/todo_handler.go

package handler

import (
    "encoding/json"
    "net/http"
    "zasral-todo/service"
)

type TodoHandler struct {
    service *service.TodoService
}

func NewTodoHandler(s *service.TodoService) *TodoHandler {
    return &TodoHandler{service: s}
}

func (h *TodoHandler) HandleTodos(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case http.MethodGet:
        todos := h.service.GetAll()
        json.NewEncoder(w).Encode(todos)
    case http.MethodPost:
        var input struct {
            Text string `json:"text"`
        }
        if err := json.NewDecoder(r.Body).Decode(&input); err != nil || input.Text == "" {
            http.Error(w, "invalid input", http.StatusBadRequest)
            return
        }
        todo := h.service.CreateTodo(input.Text)
        json.NewEncoder(w).Encode(todo)
    default:
        http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
    }
}

test/todo_test.go

package test

import (
    "testing"
    "zasral-todo/repository"
    "zasral-todo/service"
)

func TestCreateTodo(t *testing.T) {
    repo := repository.NewInMemoryRepo()
    srv := service.NewTodoService(repo)

    todo := srv.CreateTodo("Test ZASRAL")

    if todo.ID != 0 {
        t.Errorf("Expected ID 0, got %d", todo.ID)
    }
    if todo.Text != "Test ZASRAL" {
        t.Errorf("Text mismatch")
    }
}

Как ZASRAL здесь соблюдён:

Принцип Как реализован Z: Zero-loyalty to bugs Минимальные проверки входных данных, покрытие тестами A: Agility Простая архитектура, легко масштабируемая S: SOLID Чёткие разделения обязанностей: handler, service, repo R: Retrospective Можно внедрить TODO-комментарии // TODO: обсудить улучшения после спринта A (again) Простая замена бэкенда, легко адаптировать L: Logic-driven decisions Все решения обоснованы: thread safety через sync.Mutex, DI через интерфейс

Хочешь расширить — легко подключается база данных, логгирование, валидация, тестирование API.

Look

SOSAL: Современный социальный подход к программированию

tolyanski Jun 2 at 20:48

Методология ZASRAL: Современный подход к разработке программного обеспечения

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

Разберём каждую из составляющих ZASRAL:

Z: Zero-loyalty to bugs (Нулевая лояльность к багам)

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

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

A: Agility (Гибкость)

Гибкость — основа современной разработки. В контексте ZASRAL это означает:

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

S: SOLID-driven development (Разработка, основанная на принципах SOLID)

Принципы SOLID — краеугольный камень качественной архитектуры:

S: Принцип единственной ответственности (Single Responsibility Principle);
O: Принцип открытости/закрытости (Open/Closed Principle);
L: Принцип подстановки Барбары Лисков (Liskov Substitution Principle);
I: Принцип разделения интерфейсов (Interface Segregation Principle);
D: Принцип инверсии зависимостей (Dependency Inversion Principle).

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

R: Retrospective after every sprint (Ретроспектива после каждого спринта)

Ретроспектива — инструмент командной эволюции. Команды, работающие по ZASRAL, обязательно проводят ретроспективу по завершении каждого спринта:

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

A: Agility one more (Гибкость снова)

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

L: Logic-driven decision making (Принятие решений, основанное на логике)

Последний принцип — осознанное принятие решений. Это означает:

избегание эмоциональных или политизированных решений;
использование данных, анализа и здравого смысла;
прозрачность в аргументации;
рациональность в выборе технологий, инструментов и процессов.

Вывод

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

+12

Look

tolyanski Jun 2 at 19:21

Альтернатив не видно. А они нужны. Вырастить ребенка одному слишком тяжело. Двух-трех детей еще сложнее.

Согласен. Но в давние времена рожали много детей в том числе потому, что их рассматривали как актив - лет через 10+ уже появляются в доме новые рабочие руки, пригодные в помощь по хозяйству / в огороде.

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

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

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

Look

tolyanski Jun 2 at 19:13

Если он умирает - он оказался нежизнеспособным в сменившемся историческом контексте.

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

Оказался совсем нежизнеспособным или все-таки удастся его возродить - тоже покажет время.

Look

tolyanski Jun 2 at 19:03

И вы полагаете это проблема?

Смотря для кого и для чего. С точки зрения сохранения семейного института - проблема.

С точки зрения конкретных людей - каждый решает для себя сам, проблема или нет.

Look

tolyanski Jun 2 at 18:53

> Почему?

Если развод выгоден, то он неизбежно состоится

Look

2 3 ...

22 23