Pull to refresh
22
1.5
Георгий Чеботарев @Georrg

Пользователь

Send message

Как американская коррупция превратила физика-ядерщика в быдло-кодера

Level of difficultyEasy
Reading time17 min
Views129K

Это история из цикла «как войти в IT», написанная старпером, ветераном броуновского движения, который помнит динозавров. Поэтому его опыт вхождения в ИТ никому не пригодится, но представляет интерес с точки зрения истории.  

Также поделюсь своим мыслями об интерфейсе инженерного ПО. Участвуя в разработках различного ПО, предназначенного для ускорения разработки сложных систем, периодически приходится выслушивать жалобы от новых пользователей на «кривой и устаревший» интерфейс ПО. Однако инженеры, погруженные в проблемы проектирования реальных железок, вообще не задают нам таких вопросов, либо потому, что уже искривили свои руки о кривой интерфейс, либо им это вообще неважно. Более того, есть два примера, когда реальные высокопрофессиональные инженеры в своей области предъявляли претензии обратного свойства, и первая версия кривая версия GUI была удобнее, а вот улучшения делали какие-то полупокеры. 

К написанию данного текста меня подтолкнула беседа с одним из крутых разрабов из «жирной» конторы, с которым мы пересеклись на яхте в Средиземном море. Узнав, что я тоже из Бауманки, и у меня свой бизнес, он заинтересовался и выспрашивал. Как я смог начать бизнес на софте, почему не пошел в большую контору, типа Yandex, Сбер и прочие. У него тоже знакомство с софтом началось как создание собственной разработки по анализу результатов металлургических испытаний в лаборатории, но закончилось работой прогером по найму. Попивая вино на яхте где-то между Турцией и Грецией в 2023 году, он предположил, что, возможно, если бы он продолжал писать софт для металлургических исследований, то, наверное, сейчас мог плавать на своей яхте, а не арендованной, и не около Турции, а на Карибах (но это не точно). А поскольку фарш невозможно провернуть назад, я решил описать свою историю успеха, так как она забавна и поучительна.

Читать далее
Total votes 382: ↑367 and ↓15+417
Comments281

Устанавливаем модель генерации изображений Stable Diffusion 3 на ComfyUI

Level of difficultyEasy
Reading time2 min
Views16K

Модель Stable Diffusion 3 вышла вчера, 12 июня, ее файлы (SD3 Medium) и примеры конфигурации были опубликованы в тот же день на Hugging Face. Попробовать модель (пока) можно только в ComfyUI и мы написали небольшую инструкцию, как это сделать.

Читать далее
Total votes 9: ↑8 and ↓1+8
Comments10

Лидерами не рождаются или принципы эффективного управления

Level of difficultyEasy
Reading time5 min
Views11K

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

В этот раз хочу поделиться с вами книгой «Лидерами не рождаются. 12 правил эффективного руководства», Джоко Виллинк. 

Читать далее
Total votes 12: ↑8 and ↓4+6
Comments22

Глубокое погружение в Java Memory Model

Reading time53 min
Views157K


Я провел в изучении JMM много часов и теперь делюсь с вами знаниями в простой и понятной форме.


В этой статье мы подробно разберем Java Memory Model (JMM) и применим полученные знания на практике. Да, в интернете накопилось достаточно много информации про JMM/happens-before, и, кажется, что очередную статью про такую заезженную тему можно пропускать мимо. Однако я постараюсь дать вам намного большее и глубокое понимание JMM, чем большинство информации в интернете. После прочтения этой статьи вы будете уверенно рассуждать о таких вещах как memory ordering, data race и happens-before. JMM — сложная тема и не стоит верить мне на слово, поэтому большинство моих утверждений подтверждается цитатами из спеки, дизассемблером и jcstress тестами.

Читать дальше →
Total votes 109: ↑109 and ↓0+109
Comments60

Многомодульность в Android с точки зрения архитектуры. От А до Я

Reading time20 min
Views64K
Всем привет!

Не так давно мы с вами осознали, что мобильное приложение — это не просто тонкий клиент, а это действительно большое количество самой разной логики, которое нуждается в упорядочивании. Именно поэтому мы прониклись идеями Clean architecture, прочувствовали, что такое DI, научились использовать Dagger 2, и теперь с закрытыми глазами способны разбить любую фичу на слои.

Но мир не стоит на месте, и с решением старых проблем приходят новые. И имя этой новой проблемы — мономодульность. Обычно об этой проблеме узнаешь, когда время сборки улетает в космос. Именно так и начинаются многие доклады про переход на многомодульность (раз, два).
Но почему-то все при этом как-то забывают, что мономодульность сильно бьет не только по времени сборки, но и по вашей архитектуре. Вот ответьте на вопросы. На сколько у вас AppComponent большой? Не встречаете ли вы периодически в коде, что фича А зачем-то дергает репозиторий фичи Б, хотя вроде такого быть не должно, ну или оно должно быть как-то более верхнеуровнево? Вообще у фичи есть какой-то контракт? А как вы организовываете общение между фичами? Есть какие-то правила?
Вы чувствуете, что мы решили проблему со слоями, то есть вертикально все вроде хорошо, но вот горизонтально что-то идет не так? И просто разбиением на пакеты и контролем на ревью не решить проблему.

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

В своей статье я хочу вам рассказать, как дошел до многомодульности именно с архитектурной точки зрения. Какие проблемы меня беспокоили, и как я их старался поэтапно решать. А в конце вас ждет алгоритм перехода с мономодульности на многомодульность без слез и боли.
Читать дальше →
Total votes 25: ↑24 and ↓1+23
Comments18

Information

Rating
1,412-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity