SOER. Страница 18
Блог программиста S0ER. Мысли, ранний доступ к видео, фоточки, короткие посты. Ничего конкретного, но что-то будет полезным.
-
SOER
В прошлом году многие мои подписчики посмотрели конференцию Яндекса для разработчиков YaTalks – в этом году она тоже будет. И я снова рекомендую вам ее посмотреть, там уже анонсировали темы про жизнь и про технологии. В техническом блоке будут отдельные треки по стекам (Frontend, Backend, ML, Mobile) и темы вокруг IT: алгоритмы, нейросети, телеметрия, локализация для iOS, монорепозитории и другие хардовые. В жизненном поговорят о том, что всем так или иначе близко: как бороться с кризисами, развивать команду и самого себя, запускать новые проекты. Как и в прошлом году, спикеров заявлено много, в том числе с международным опытом. Сам планирую послушать дебаты про необходимость тимлидов и доклад о нейросетках Регистрация бесплатная, все пройдет онлайн 3-4 декабря. -
SOER
Я снова оживил формат S0ER TALKS и теперь он стал по-настоящему "TALKS", вообще не редактируя, сразу с записи и в прод. Да я обленился или хочу просто почесать языком, это уже вам виднее - https://www.youtube.com/watch?v=nCPTiUdTgn0 -
SOER
Пример того как не особо напрягаясь за полтора часа можно собрать инфраструктуру на докере, которая покроет абсолютно все потребности начинающего стартапа как в росте, так и в архитектуре. Плюс уже настроенный рабочий workflow через gitlab. Конечно, можно костылить через LAMP и PHP и по старинке все вручную устанавливать, но я не понимаю зачем, если с нуля до "ready to go" занимает жалкие 90 минут? https://www.youtube.com/watch?v=o91Dnq24sEQ UPD. вопрос не в PHP, к нему претензий нет, вопрос в том чтобы унифицировать процесс разработки, а не проходить вручную все круги -
Реклама
-
SOER
Возобновил приём новых участников в ITUBETEAM позвал Рому Сакутина, пока жду его ответа. Вопрос такой - кого из русскоговорящих ютуберов вы считаете профи своего дела? -
SOER
По поводу Яндекс.Документов надо сделать уточнение, вроде как они используют Р7-офис, который в свою очередь много чего взял от OnlyOffice. Т.е. это сила OpenSource опять дала о себе знать. Так что получается, что в большей мере молодцы не столько Яндекс-разработчики, а ребята из OnlyOffice и Р7, но в целом это не отменяет того, что у Яндекса много классных сервисов. Пишу это потому что "публичные персоны должны быть правдивы и не предвзяты". -
SOER
Ребята, я не люблю "балаболов", если есть конструктивная критика, то давайте обсудим. Если у вас детство в жопе играет, то отпишитесь от канала, вы реально только мешаете, пользы от вас ноль. 
-
SOER
Постепенно отказываюсь от гугловых сервисов, сейчас перевожу документы на Yandex Документы. Не ожидал, но решение Яндекса мне нравится в разы больше. Ребятам разрабам большой респект! Очень круто сделали. -
SOER
Моё рабочее место выглядит так... как думаете, надо делать обзор на канале? 
-
SOER
В этом году были две встречи с подписчикам - одна в Сочи, другая в Санкт-Петербурге. Обе встречи были ламповыми и спонтанными. На стриме из Питера был вопрос - какой город следующий? Напишите в комментариях город в котором вы бы хотели чтобы прошла встреча с подписчиками. Спамить не надо, если ваш город уже есть, просто поставьте за него любую реакцию. -
SOER
Говорят "Если ты молоток, то все проблемы вокруг кажутся гвоздями". Я вот долгое время работал в архитектуре и все проблемы вокруг мне кажутся от того, что нет "технологии" работы. Вот сейчас собрали команду для работы над Naris. Получилось много (сейчас 28 человек). И о чем я думаю? О технологии работы таких команд! Напомню, я на общественных началах набираю команду для которой выступаю в качестве ментора. У нас действует классический подход с ограничением по времени (семестрам) - 3 месяца мы работаем вместе. потом я делаю новый набор желающих прокачаться в командной работе. Технология работы - это подготовка первичной информации и правил организации команды, уже сейчас я выделил обязательные шаги, которые сводятся к следующему: - знакомство - каждый рассказывает о своих целях и задачах - вводная часть - определяем объем работ, которые хотим сделать, фиксируем в виде требований - пробные задачи - делаем по одно пробной задаче, чтобы отфильтровать тех кто ошибся (ничего страшного, если в процессе люди поняли, что это не их путь) - разбор ошибок и фиксация состава команды (предполагается, что те кто хотел уйти уже ушел) - выдача доступа к материалам - разбиение на подгруппы (парное программирование) и переход на спринты - стандартный "спринтовый" цикл: обсуждение, выполнение, ревью, устранение ошибок, фиксация - подведение итогов -
SOER
Ребята, если есть конструктивная критика по s0er.ru в плане улучшения юзабилити и вёрстки, или какие-то другие важные на ваш взгляд моменты, то напишите в комментарии. -
SOER
Изложил свои мысли по поводу переписывания с нуля. Получился лонгрид, который я вынес на SOER MEDIA - https://s0er.ru/documents/article/3751 -
SOER
Самое важное, что надо знать про архитектуру, кроется в простой фразе - "Решения, которые вы приняли сегодня, определят решения, которые вы примите завтра." -
SOER
В 2000-ом году Джоэл Спольки сформулировал 12 вопросов, которые показывают зрелость вашей команды. Это очень хороший список того, чего у плохих команд никогда нет. Минимальный "проходной бал" - 6. Если ваша команда набирает меньше 6, то вам надо срочно с этим что-то делать. www.joelonsoftware.com/2000/08…ter-code -
SOER
Я много раз публиковал подборку книг по архитектуре программного обеспечения, теперь вынес ее на SOER.MEDIA, надеюсь больше не потеряется. https://s0er.ru/documents/article/3741 #книга #ссылки -
Реклама
-
SOER
Ожидаемые пример на пост про приложения из "говна и палок", которые стали большими. Сразу скажу, что все три не являются таковыми: Twitter - начинался как внутрений проект компании Odeo, который создавался сильной командой разработчиков, один только Дорси уже до этого имел опыт проектирования и созданя аналогичных систем. И являлся к 2006 году очень сильным архитектором. Так что там с самого начала работала сильная команда. Microsoft - тут все просто, Билл вообще не заморачивался на создание продукта, он купил готовую OS, которая работала и поставлялась на ПК от IBM. Тоже пример когда изначально было нормальное готовое решение. Facebook - один из "близких" к обсуждаемой задаче примеров. Но опять же, до Facebook был Facemash, при создании самого Facebook Цукерберг работал над прототипом братьев Уинклвосс, идея которого и легла в основу Facebook. Правда, остается вопрос был ли прототип или все же была только идея. Насколько я читал. прототип таки был, потому что Цукерберг в суде доказывал, что ни строчки кода он не взял. Но взял ли он архитектурные идеи и насколько вообще заимствовал из этого проекта - неизвестно. Одно точно, опыт создания аналогичных проектов у Марка был и очевидно, что он его использовал для запуска Facebook. Проблема приложений, которые собраны не пойми из чего, не пойми как - это сопровождение. Если проект выстреливает, то рост пользовательской базы слишком высокий, просто не успеешь переписать грамотно. Поэтому приложения которые "выстрелили", должны быть достаточно продуманы, чтобы их можно было сопровождать и наращивать пользовательскую базу. -
SOER
Архитектурный подход к построению вашего продукта не означает "долго". Он означает "учитывая вектор развития". Вы должны определиться со своими целями, прежде чем начнёте куда либо двигаться, а далее на каждом шаге проверять придерживаетесь курса или нет. Для этого нужно выработать принципы построения проекта и научиться отвечать на вопрос "зачем?". Например, зачем я использую СУБД, а не пишу данные в файл. Если не можете ответить на вопрос "зачем", то вероятно у вас нет необходимости в СУБД. На уровне принципов архитектурный подход определяет и правила ведения документации, и уровень детализации проекта и т.д. Делая стартап вы можете сильно упростить требования к ведению проекта, а разрабатывая космический аппарат, наоборот усложнить. Есть разные техники, помогающие выработать нужные привычки, например "проговаривание" - "я делаю этот класс потому что ..." В целом архитектурный подход ничуть не "дольше", чем "делаем как получится". Наоборот, он призван уменьшить энтропию вашего проекта и увеличить синергию команды. Проблема лишь одна - нужно учиться, но это сложно, куда проще сказать "нам и так сойдет", а потом убедить себя, что все так работают и ничего. -
SOER
Часто слышу мол если вы сделали продукт (программу) из говна и палок, но при этом заработали денег, то всегда сможете нанять команду толковых программистов, чтобы переписать проект. В этом утверждении все близко сердцу говноделов, кроме маленькой детали - нормальных примеров нет.