О сторипоинтах
tl;dr:
Сторипоинты это работа в физическом смысле. А умение справится с работой у разработчика — это мощность. Все мы помним из физики, что мощность пропорциональна отношению работы ко времени. Или иначе работа это мощность, умноженная время. Поэтому называть планируемое время работы над задачей можно и нужно. Только после этого нужно только приводить к работе-сторипоинтам правильно, домножая на мощность. Разработчик это в своей голове вряд ли сделает это как нужно.
#полныйаджайл
Второй выпуск рубрики «Полный Аджайл» с заметками по техпроцессам разработки от читателей. Присылайте ваши мысли и описание ваших техпроцессов мне личным сообщением, ведь такие ценные знания должны быть общим достоянием.
О сторипоинтах
tl;dr:
Sp = t • GradeСторипоинты это работа в физическом смысле. А умение справится с работой у разработчика — это мощность. Все мы помним из физики, что мощность пропорциональна отношению работы ко времени. Или иначе работа это мощность, умноженная время. Поэтому называть планируемое время работы над задачей можно и нужно. Только после этого нужно только приводить к работе-сторипоинтам правильно, домножая на мощность. Разработчик это в своей голове вряд ли сделает это как нужно.
#полныйаджайл
Друзья, мы совершенно пропустили тот момент, когда нас стало три тысячи. Мне очень приятно, что у нас собралась такое хорошее и активное комьюнити разработчиков. Вы самые лучшие 🎉.
Я знаю, что кнопочки с лайкодизлайками ставят далеко не все, из тех, что читает канал, а не просто на него подписан. У каждого своя причина, но сегодня я хотел бы вас попросить, в порядке исключения все-таки нажать на воздушный шарик (🎈), если вы читаете это сообщение. Нажмите на робота (🤖), если вы не читаете канал, а просто на него подписаны, а на пришельца (👽) не нажимайте вообще, пожалуйста.
Спасибо!
Я знаю, что кнопочки с лайкодизлайками ставят далеко не все, из тех, что читает канал, а не просто на него подписан. У каждого своя причина, но сегодня я хотел бы вас попросить, в порядке исключения все-таки нажать на воздушный шарик (🎈), если вы читаете это сообщение. Нажмите на робота (🤖), если вы не читаете канал, а просто на него подписаны, а на пришельца (👽) не нажимайте вообще, пожалуйста.
Спасибо!
Экстраполяция IT pinned «Друзья, мы совершенно пропустили тот момент, когда нас стало три тысячи. Мне очень приятно, что у нас собралась такое хорошее и активное комьюнити разработчиков. Вы самые лучшие 🎉. Я знаю, что кнопочки с лайкодизлайками ставят далеко не все, из тех, что читает…»
О мотивации менеджеров и коллективной стратегии
В команде почти всегда есть тот, кто рвётся в менеджеры. Вот на эту здоровую голову можно и переложить со своей здоровой проблемы джиры, мотивируя это каким-то повышением. Как показывает практика, люди готовы ждать этого повышения два-три года, если их периодически хвалить и всячески словесно поощрять. За это время человек может заработать себе новое звание «за выслугу лет» или просто потому, что стал опытнее и круче. Но все это под соусом его управленческих навыков и лидерских качеств.
Если нет такого человека, назначаешь срам-мастером каждого работника по спринту. От него требуешь планирования, оценок и ретроспектив. А дальше - он уже делает все по накатанной. Но команда должна понимать, что в следующем спринте его место займёт кто-то другой. И коллективная стратегия работает лучше индивидуальной. Главное, чтобы она была направлена на тикеты, а не против твоих процессов.
#полныйаджайл
В эфире наша уже постоянная рубрика «Полный Аджайл» с заметками по техпроцессам разработки от читателей.
О мотивации менеджеров и коллективной стратегии
В команде почти всегда есть тот, кто рвётся в менеджеры. Вот на эту здоровую голову можно и переложить со своей здоровой проблемы джиры, мотивируя это каким-то повышением. Как показывает практика, люди готовы ждать этого повышения два-три года, если их периодически хвалить и всячески словесно поощрять. За это время человек может заработать себе новое звание «за выслугу лет» или просто потому, что стал опытнее и круче. Но все это под соусом его управленческих навыков и лидерских качеств.
Если нет такого человека, назначаешь срам-мастером каждого работника по спринту. От него требуешь планирования, оценок и ретроспектив. А дальше - он уже делает все по накатанной. Но команда должна понимать, что в следующем спринте его место займёт кто-то другой. И коллективная стратегия работает лучше индивидуальной. Главное, чтобы она была направлена на тикеты, а не против твоих процессов.
#полныйаджайл
Сегодня мы обсудим классическую задачу на понимание ложных убеждений (false belief task).
Ребёнку показывают двух кукол, Салли и Энн; у Салли есть корзинка, а у Энн — коробка. Ребёнок видит, как Салли кладёт свой шарик в корзинку и уходит. Пока Салли нет, озорница Энн перекладывает шарик из корзинки в свою коробку и тоже уходит. Теперь Салли возвращается. Ребёнка спрашивают: «Где Салли будет искать свой шарик»?
Совершенно очевидно, что Салли будет искать шарик в корзине, потому как наблюдателю известно, что Салли не ведает о том, что Энн перепрятала шар. И очевидно это тем, кто наблюдает за наблюдателем и видит, что он видит и какой вопрос ему задают.
Чтобы усложнить пример, можно наблюдателя интегрировать в систему и заставить взаимодействовать с Энн и Салли. Например, выдать несколько коробок и разрешить менять положение шара после Энн так, чтобы и Энн и Салли точно знали где находится шар. Или заменим существительные в этом эксперименте на что-нибудь айтишное.
Например, тестировщица Шьямала нашла в системе баг и хочет рассказать программисту Раджешу и менеджеру Кумару о нем. Молодая и неопытная Шьямала вполне в состоянии сказать «ребята, у вас сайт не работает», более опытная скажет «У вас в профиле пользователя баг» и только матёрая кюэйщица напишет по шагам как воспроизвести этот баг.
Многие могут подумать, что это достаточно очевидно и любая шьямала уже давно не делает глупостей таких вот глупостей. Но достаточно вспомнить случаи, когда хотелось взять в руки сарумановский шар, чтобы понять что же коллега пытается донести, как все становится на свои места. Эксперимент Салли и Энн, к слову, в большинстве своем дети до четырех лет пройти не могут. Пятилетки практически все отвечают правильно.
Ребёнку показывают двух кукол, Салли и Энн; у Салли есть корзинка, а у Энн — коробка. Ребёнок видит, как Салли кладёт свой шарик в корзинку и уходит. Пока Салли нет, озорница Энн перекладывает шарик из корзинки в свою коробку и тоже уходит. Теперь Салли возвращается. Ребёнка спрашивают: «Где Салли будет искать свой шарик»?
Совершенно очевидно, что Салли будет искать шарик в корзине, потому как наблюдателю известно, что Салли не ведает о том, что Энн перепрятала шар. И очевидно это тем, кто наблюдает за наблюдателем и видит, что он видит и какой вопрос ему задают.
Чтобы усложнить пример, можно наблюдателя интегрировать в систему и заставить взаимодействовать с Энн и Салли. Например, выдать несколько коробок и разрешить менять положение шара после Энн так, чтобы и Энн и Салли точно знали где находится шар. Или заменим существительные в этом эксперименте на что-нибудь айтишное.
Например, тестировщица Шьямала нашла в системе баг и хочет рассказать программисту Раджешу и менеджеру Кумару о нем. Молодая и неопытная Шьямала вполне в состоянии сказать «ребята, у вас сайт не работает», более опытная скажет «У вас в профиле пользователя баг» и только матёрая кюэйщица напишет по шагам как воспроизвести этот баг.
Многие могут подумать, что это достаточно очевидно и любая шьямала уже давно не делает глупостей таких вот глупостей. Но достаточно вспомнить случаи, когда хотелось взять в руки сарумановский шар, чтобы понять что же коллега пытается донести, как все становится на свои места. Эксперимент Салли и Энн, к слову, в большинстве своем дети до четырех лет пройти не могут. Пятилетки практически все отвечают правильно.
Forwarded from noTieinIT - Об IT без галстуков
#личностноеразвитие
Про повышения. Большинство наемных сотрудников считает, что руководство его заметит, оценит и повысит зарплату. Это большое заблуждение. Ни один руководитель в здравом уме не будет увеличивать расходную часть, тем самым уменьшая доходную. Если вы встречали компанию в которой происходит периодическая оценка персонала и сама компания инициирует повышения, то это заслуга HR департамента и им удалось "продать" руководству эту необходимость. Например, еще лет 5 назад, в IT был бурный рост ставок и дабы гребец не сбежал, его повышали. С тех пор ставки доросли до своего максимума, рынок немного стабилизировался.
Как же получить повышение? Ответ очевиден и прост, только вот признавать его мало кто желает... Надо показать свою ценность. Больше и усердней работать? Нет. Нужно решать задачи бизнеса. Тут возможны разные сценарии. Можно прийти с анализом, мол, такой-то процесс неэффективен, эта система работает недостаточно быстро, там затраты можно снизить, а тут можно малой кровью сделать продукт лучше. Это, безусловно, лучше чем не делать ничего или ныть о том как все плохо. У этого подхода есть недостаток: то что сотрудник считает важным, может таким не являться для руководителя. При отказе же, сотрудник демотивируется и может впасть в депрессию.
Самый верный вариант - это поговорить с руководителем и выяснить какие задачи стоят перед руководителем, чем можно ему помочь, какие есть финансовые и временные ограничения. Затем стоит тщательно проанализировать полученные данные и идти на повторную встречу с предложениями по решению задач. Помните про ценность? Ценность в том, чтобы предложить наиболее эффективное решение, продумать все до мелочей, быть готовым взяться за реализацию и решить проблему бизнеса. Если решения нет, то лучше прямо об этом сообщить, а не пытаться придумать хоть что-то. Если уже браться, то обязательно доводить до конца, а то второго шанса может и не выпасть.
@noTieinIT
Про повышения. Большинство наемных сотрудников считает, что руководство его заметит, оценит и повысит зарплату. Это большое заблуждение. Ни один руководитель в здравом уме не будет увеличивать расходную часть, тем самым уменьшая доходную. Если вы встречали компанию в которой происходит периодическая оценка персонала и сама компания инициирует повышения, то это заслуга HR департамента и им удалось "продать" руководству эту необходимость. Например, еще лет 5 назад, в IT был бурный рост ставок и дабы гребец не сбежал, его повышали. С тех пор ставки доросли до своего максимума, рынок немного стабилизировался.
Как же получить повышение? Ответ очевиден и прост, только вот признавать его мало кто желает... Надо показать свою ценность. Больше и усердней работать? Нет. Нужно решать задачи бизнеса. Тут возможны разные сценарии. Можно прийти с анализом, мол, такой-то процесс неэффективен, эта система работает недостаточно быстро, там затраты можно снизить, а тут можно малой кровью сделать продукт лучше. Это, безусловно, лучше чем не делать ничего или ныть о том как все плохо. У этого подхода есть недостаток: то что сотрудник считает важным, может таким не являться для руководителя. При отказе же, сотрудник демотивируется и может впасть в депрессию.
Самый верный вариант - это поговорить с руководителем и выяснить какие задачи стоят перед руководителем, чем можно ему помочь, какие есть финансовые и временные ограничения. Затем стоит тщательно проанализировать полученные данные и идти на повторную встречу с предложениями по решению задач. Помните про ценность? Ценность в том, чтобы предложить наиболее эффективное решение, продумать все до мелочей, быть готовым взяться за реализацию и решить проблему бизнеса. Если решения нет, то лучше прямо об этом сообщить, а не пытаться придумать хоть что-то. Если уже браться, то обязательно доводить до конца, а то второго шанса может и не выпасть.
@noTieinIT
Интересное дело, все вот знают о существовании определений «говнокод» и «костыль». Эти два термина существуют отдельно друг от друга, что не удивительно, ведь означают они разные вещи. Хотя же можно подумать, что говнокод — это набор костылей с примесью ещё чего-то. Но костыль в коде далеко не всегда является говнокодом. И наоборот, далеко не каждый говнокод можно смело классифицировать, как костыль. Очень похоже на то, что нужно срочно устроить ликбез. Я предлагаю основательно разобраться в этом вопросе.
Уверен, что подавляющее большинство подписчиков канала мастерски умеют определять говнокод, особенно чужой, ведь это самый первый навык, которым овладевает разработчик в нашей профессии. Что для вас говнокод? Что такое костыль по вашему мнению? Присылайте личным сообщением мне (@aratak) с пометкой #айтермин ваше определение этих замечательных определений.
Свою версию вместе с вашими присланными можно будет почитать по тегу ближайшие недели.
Уверен, что подавляющее большинство подписчиков канала мастерски умеют определять говнокод, особенно чужой, ведь это самый первый навык, которым овладевает разработчик в нашей профессии. Что для вас говнокод? Что такое костыль по вашему мнению? Присылайте личным сообщением мне (@aratak) с пометкой #айтермин ваше определение этих замечательных определений.
Свою версию вместе с вашими присланными можно будет почитать по тегу ближайшие недели.
«Правило бутерброда» в современную айти-эпоху заиграло новыми красками и сейчас должно называться «правилом бэкапа».
Вообще, процесс бекапа не так интересен, как процесс восстановления из бекапа. Поэтому постановка вопроса «делаете ли бекапы» в корне не верен. Правильный вопрос: «Умеете ли вы восстанавливать из бекапов?».
Дальше должна идти тирада об полезности учебных тревог в военных частях и аналогии с падением серверов, но я её лучше оставлю для самостоятельного размышления.
Вообще, процесс бекапа не так интересен, как процесс восстановления из бекапа. Поэтому постановка вопроса «делаете ли бекапы» в корне не верен. Правильный вопрос: «Умеете ли вы восстанавливать из бекапов?».
Дальше должна идти тирада об полезности учебных тревог в военных частях и аналогии с падением серверов, но я её лучше оставлю для самостоятельного размышления.
Короткие новости по рубрике #айтермин
Во-первых, спасибо вам, друзья, за такую большую активность. Предложений по формулировке «костыля» и «говнокода» пришло множество. Постараемся рассказать о всех и ничего не упустить. Некоторые, даже планируем опубликовать целиком, как есть. Следите за активностью по тегу.
Еще хотелось отметить, что подавляющее большинство ответов оперировало такими понятиями, как «хорошо», «понятно», «быстро», «тяжело» и «удобно». Это безусловно хороший вариант определения, при условии, что нужно договориться заранее что же такое «хорошо» и «удобно». Думается мне, что договориться о точном определении таких терминов будет ой как не просто.
Некоторые ответы описывали костыль, как облегченную версию говнокода. Ну, которая, в отличие от говнокода, «изолированна», «не мешает архитектуре» и «всего лишь попахивает, а не воняет». Как по мне, если смешать килограмм говна и килограмм бананов, то мы получим два килограмма говна, а не смузи из съедобного и плохо пахнущего.
Если вам есть что сказать по этой теме, пишите личным сообщением мне (@aratak) с пометкой тегом.
Продолжение следует!
Во-первых, спасибо вам, друзья, за такую большую активность. Предложений по формулировке «костыля» и «говнокода» пришло множество. Постараемся рассказать о всех и ничего не упустить. Некоторые, даже планируем опубликовать целиком, как есть. Следите за активностью по тегу.
Еще хотелось отметить, что подавляющее большинство ответов оперировало такими понятиями, как «хорошо», «понятно», «быстро», «тяжело» и «удобно». Это безусловно хороший вариант определения, при условии, что нужно договориться заранее что же такое «хорошо» и «удобно». Думается мне, что договориться о точном определении таких терминов будет ой как не просто.
Некоторые ответы описывали костыль, как облегченную версию говнокода. Ну, которая, в отличие от говнокода, «изолированна», «не мешает архитектуре» и «всего лишь попахивает, а не воняет». Как по мне, если смешать килограмм говна и килограмм бананов, то мы получим два килограмма говна, а не смузи из съедобного и плохо пахнущего.
Если вам есть что сказать по этой теме, пишите личным сообщением мне (@aratak) с пометкой тегом.
Продолжение следует!
У обычных разработчиков (серверных, если хотите), а не у «фронтенд-разработчиков» с идентификацией все более или менее аккуратно и очевидно. Фраза «я разработчик и я знаю питон, скалу, руби, эрланг и сервера настраивать» никого не удивляет и вполне естественна. А вот «я фронтенд-девелопер и умею все, что в браузере работает», звучит почему-то раздуто.
Еще подмечено, что у крутых нодэджеэсеров считается зазорным уметь хорошо верстать. Но это не точно.
Еще подмечено, что у крутых нодэджеэсеров считается зазорным уметь хорошо верстать. Но это не точно.
Разнообразные формулировки говнокода сходятся в одном субъективном критерии — это когда плохо. Ну, то есть, трудно понять, трудно сопровождать, плохо написано, легко нечаянно сломать, некрасиво. Самое красивое определение этого термина — код без структуры или с большим количеством исключений из набора правил, принятым текущей структурой. Но с ним и вопроса особого нет, вопрос с костылём поинтереснее.
Костыль — частично пересекающееся с этим понятие, как на диаграммах венна, не весь говнокод — костыль и не любой костыль — говнокод, хотя последнее встречается пореже. Костыль — это когда что-то используется не по прямому назначению, а случайно, сайдэффектом. То есть, когда ты читаешь код, некоторое время его перевариваешь, понимаешь, почему это работает и восхищённый чужой изворотливостью крутишь головой. Или когда ты пишешь код, в определённый момент весело говоришь «о, так оно сейчас вот так заработает!» добиваешь парой слов, запускаешь и правда работает, а ты хитро хихикаешь.
Известный любому программисту термин "багофича" — это тоже о костыле. Только не сама багофича, а вот когда есть баг, а ты его в коде используешь как фичу. Частный случай костыля.
#айтермин
Костыль — частично пересекающееся с этим понятие, как на диаграммах венна, не весь говнокод — костыль и не любой костыль — говнокод, хотя последнее встречается пореже. Костыль — это когда что-то используется не по прямому назначению, а случайно, сайдэффектом. То есть, когда ты читаешь код, некоторое время его перевариваешь, понимаешь, почему это работает и восхищённый чужой изворотливостью крутишь головой. Или когда ты пишешь код, в определённый момент весело говоришь «о, так оно сейчас вот так заработает!» добиваешь парой слов, запускаешь и правда работает, а ты хитро хихикаешь.
Известный любому программисту термин "багофича" — это тоже о костыле. Только не сама багофича, а вот когда есть баг, а ты его в коде используешь как фичу. Частный случай костыля.
#айтермин
Сегодня, на правах субботнего вечернего поста, хочу высказать свое «фи» современному ИИ. До человеческих способностей ему еще ой как далеко :-)
Лайвхаки от экстраполяции.
Поразительно, насколько действие капслока по-умолчанию бесполезное. В дополнение эта клавиша считается клавишей модификации, и поэтому не может быть использована для чего-нибудь полезного без комбинации с другими кнопками. Именно по этой причине переключение языка с помощью ctrl+shift на макоси невозможна. С точки зрения системы никакая кнопка нажата не была, а были лишь зажаты клавиши модификации.
Самая, на мой взгляд, удобная функция на кнопке caps lock — переключение языков. В старых системах это решалось сторонними программами, где на уровне драйверов клавиатуры клавиша caps lock вдруг становилась какой-нибудь клавишей 'f15', но в последних версиях операционной системы это работать перестало.
Вместо этого появилась встроенная в систему возможность переключать язык по капслоку. Прелесть будет состоять в том, что можно оставить старое-доброе 'cmd+space' для переключения и в дополнение к нему — 'caps lock'. И плавно привыкать к капслоку.
Поразительно, насколько действие капслока по-умолчанию бесполезное. В дополнение эта клавиша считается клавишей модификации, и поэтому не может быть использована для чего-нибудь полезного без комбинации с другими кнопками. Именно по этой причине переключение языка с помощью ctrl+shift на макоси невозможна. С точки зрения системы никакая кнопка нажата не была, а были лишь зажаты клавиши модификации.
Самая, на мой взгляд, удобная функция на кнопке caps lock — переключение языков. В старых системах это решалось сторонними программами, где на уровне драйверов клавиатуры клавиша caps lock вдруг становилась какой-нибудь клавишей 'f15', но в последних версиях операционной системы это работать перестало.
Вместо этого появилась встроенная в систему возможность переключать язык по капслоку. Прелесть будет состоять в том, что можно оставить старое-доброе 'cmd+space' для переключения и в дополнение к нему — 'caps lock'. И плавно привыкать к капслоку.
Разработчик должен многое уметь и многое знать, постоянно развиваться. И именно поэтому фронтенд-девелопера стоит переименовать в простого джаваскрипт-разработчика, и ни в коем случае не в react/angular-разработчика. Еще стоит отличать javascript-разработчика от typescript-разработчика, а от elm-разработчика не требовать знать coffeescript. Само собой, разработчик может знать несколько языков, тогда он будет гордо носить титулы, например, typescript-разработчика и elm-разработчика одновременно.
Конечно, тенденции серверной разработки говорят нам, что вполне успешно могут существовать scala-разработчики, которые вообще не умеют писать на java или elixir-разработчики, которые ни в зуб ногой в erlang. И это нормально.
Теперь ограничим это множество с другой стороны. Инструментарных разработчиков, вне зависимости от вероисповедания, вроде django-разработчиков, rails-разработчиками и angular-разработчиками нужно отправлять куда-нибудь учиться, а не программировать. Вместе под руку с операторами фотошопа, администраторов mysql и css-верстальщиками.
Возражение «везде есть свои особенности и костыли, которые надо знать» говорит, что действительно везде свои особенности и все надо, мать его, знать. И никакой фулстековостью или узкой специализацией это решить не получится.
Конечно, тенденции серверной разработки говорят нам, что вполне успешно могут существовать scala-разработчики, которые вообще не умеют писать на java или elixir-разработчики, которые ни в зуб ногой в erlang. И это нормально.
Теперь ограничим это множество с другой стороны. Инструментарных разработчиков, вне зависимости от вероисповедания, вроде django-разработчиков, rails-разработчиками и angular-разработчиками нужно отправлять куда-нибудь учиться, а не программировать. Вместе под руку с операторами фотошопа, администраторов mysql и css-верстальщиками.
Возражение «везде есть свои особенности и костыли, которые надо знать» говорит, что действительно везде свои особенности и все надо, мать его, знать. И никакой фулстековостью или узкой специализацией это решить не получится.
Проклятые кастомные селекты.
Когда дизайн требует чего-то этакого от инпутов, верстальщики приседают в шпагате и делают довольно сумасшедшие вещи, типа картинки внутри инпута, но оставляют тег
Стандартный селект прекрасен, он закрывается по Esc, он открывается по Cmd+вниз, в нём работает поиск (откройте селект и начните печатать), и ничего из этого ваши кастомные селекты в большинстве своём делать не умеют. Просто потому, что до этого не доходят руки у разрабатывающего этот компонент верстальщика.
Конечно, есть удачные решения, вроде бутстраповского кастомного селекта, джикверишного селекта и аналогичной реактджс-компоненты знаменитой. Но даже в этих случаях количество протекающих абстракций не ноль, а просто меньше, чем в остальных случаях. Если вам кажется, что вы знаете контрпример, в котором набор дивов ведет себя ну прям как селект точь-в-точь и никаких абстракций не протекает, то тут же вспомните об автозаполнении форм в браузерах или о длинных выпадающих списках и невысоких браузерных окнах (как на картинке).
К слову, когда браузеры были еще маленькими, эксплорер только мечтал о седьмой версии и хрома вообще не существовало, селекты были еще более независимыми. Некоторые браузеры, видимо в силу каких-то внутренних ограничений, отказывались реализовывать выпадающие списки стандартными способами и в ход шли костыли. Такие топорные дубовые неотшлифованные тяжелые костыли. Никакой речи о дополнительных стилях к селекту вообще не шло, там проблемы были намного серьезнее. Например, никакой див с абсолютным позиционированием и с увеличенным z-индексом не мог быть выше селект-инпута просто потому, что выпадающий список не являлся частью документа. Все селекты рендерились отдельно от всего документа и, собственно, поверх документа. Если вдруг хотелось сделать что-то вроде модального окна, то дополнительным джаваскриптом, при открытии любого модального див-элемента, всем выпадающим спискам на странице делался ниндзя-прием в виде 'visibility: hidden'. Еще можно было заметить на тормозящих компьютерах, что расчет позиции селекта на странице слегка отставал при скроллировании страницы. Селект немного позже рассчитывал свою позицию, чем это делала сама страница и перемещался с легким запозданием.
Очень хороший пример костыля в рубрику #айтермин.
Когда дизайн требует чего-то этакого от инпутов, верстальщики приседают в шпагате и делают довольно сумасшедшие вещи, типа картинки внутри инпута, но оставляют тег
<input>. Но если появляются стили для выпадающего списка, тег <select> и его друзья <option> отправляются на помойку и вылезают <div> и джаваскрипт. Ну не пускают браузеры даже в распоследнем html/css кастомизировать селекты. Как же это печалит!Стандартный селект прекрасен, он закрывается по Esc, он открывается по Cmd+вниз, в нём работает поиск (откройте селект и начните печатать), и ничего из этого ваши кастомные селекты в большинстве своём делать не умеют. Просто потому, что до этого не доходят руки у разрабатывающего этот компонент верстальщика.
Конечно, есть удачные решения, вроде бутстраповского кастомного селекта, джикверишного селекта и аналогичной реактджс-компоненты знаменитой. Но даже в этих случаях количество протекающих абстракций не ноль, а просто меньше, чем в остальных случаях. Если вам кажется, что вы знаете контрпример, в котором набор дивов ведет себя ну прям как селект точь-в-точь и никаких абстракций не протекает, то тут же вспомните об автозаполнении форм в браузерах или о длинных выпадающих списках и невысоких браузерных окнах (как на картинке).
К слову, когда браузеры были еще маленькими, эксплорер только мечтал о седьмой версии и хрома вообще не существовало, селекты были еще более независимыми. Некоторые браузеры, видимо в силу каких-то внутренних ограничений, отказывались реализовывать выпадающие списки стандартными способами и в ход шли костыли. Такие топорные дубовые неотшлифованные тяжелые костыли. Никакой речи о дополнительных стилях к селекту вообще не шло, там проблемы были намного серьезнее. Например, никакой див с абсолютным позиционированием и с увеличенным z-индексом не мог быть выше селект-инпута просто потому, что выпадающий список не являлся частью документа. Все селекты рендерились отдельно от всего документа и, собственно, поверх документа. Если вдруг хотелось сделать что-то вроде модального окна, то дополнительным джаваскриптом, при открытии любого модального див-элемента, всем выпадающим спискам на странице делался ниндзя-прием в виде 'visibility: hidden'. Еще можно было заметить на тормозящих компьютерах, что расчет позиции селекта на странице слегка отставал при скроллировании страницы. Селект немного позже рассчитывал свою позицию, чем это делала сама страница и перемещался с легким запозданием.
Очень хороший пример костыля в рубрику #айтермин.
Сейчас пишу кастомные селекты.
В том, который «мульти», еще пытался делать нормальную работу с клавиатурой, а в самом обычном просто забил. Если пытаться повторять поведение нативного, то можно потратить неделю, а див с текстом и второй див с выпадающим списком никто никогда в неделю не оценивает. Но еще ты забыл про кастомные селекты на мобильных девайсах. Это отдельная боль для пользователя, а нативные селекты вообще ни на что не похожи, взять те же айосные барабаны. Ну и понятное дело пользователь очень плохо будет воспринимать кастомное дизайнерское говно.
А еще интересна идея эволюции нативных контролов, взять те же скроллбары. Раньше библиотек, реализующих кастомные скроллы, был вагон и маленькая тележка. И если в то время дизайнер не устоял бы перед искушением добавить немного красоты в его детище, то сейчас его скролл, каким бы крутым он ни был в то время, будет смотреться довольно уныло на фоне аккуратных, иногда даже самоустраняющихся при пассивном состоянии нативных скроллов. Конечно ни один дизайн не живет так долго, но все-равно круто всегда держать в голове возможность эволюции браузеров при проектировании дизайна.
Дополнение к прошлому посту.
Короче, картинок было две — логотип рубрики и иллюстрация к тексту. Опубликовалась один логотип. По всей видимости, добавить две картинки к посту нельзя. Исправляюсь отдельным постом.
Ну, а чтобы не постить картинку просто так, опубликую еще шикарный присланный отзыв личным сообщением от читателя. Поддержите лайком, пусть будут больше таких вот личных сообщений!
Сейчас пишу кастомные селекты.
В том, который «мульти», еще пытался делать нормальную работу с клавиатурой, а в самом обычном просто забил. Если пытаться повторять поведение нативного, то можно потратить неделю, а див с текстом и второй див с выпадающим списком никто никогда в неделю не оценивает. Но еще ты забыл про кастомные селекты на мобильных девайсах. Это отдельная боль для пользователя, а нативные селекты вообще ни на что не похожи, взять те же айосные барабаны. Ну и понятное дело пользователь очень плохо будет воспринимать кастомное дизайнерское говно.
А еще интересна идея эволюции нативных контролов, взять те же скроллбары. Раньше библиотек, реализующих кастомные скроллы, был вагон и маленькая тележка. И если в то время дизайнер не устоял бы перед искушением добавить немного красоты в его детище, то сейчас его скролл, каким бы крутым он ни был в то время, будет смотреться довольно уныло на фоне аккуратных, иногда даже самоустраняющихся при пассивном состоянии нативных скроллов. Конечно ни один дизайн не живет так долго, но все-равно круто всегда держать в голове возможность эволюции браузеров при проектировании дизайна.
На просторах интернета обнаружилась вот такая вот картинка, по стандартному шаблону мема. Сначала показалось, что несмешная. Потом показалась смешной, потом показалась слишком философской.
Действительно, многие ругают излишнюю бюрократию управления проектов, а предложить что-то стоящее очень тяжело и сильно индивидуально, зависит от случая, чтобы вписывать это в какую-то стандартную концепцию. #полныйаджайл
Действительно, многие ругают излишнюю бюрократию управления проектов, а предложить что-то стоящее очень тяжело и сильно индивидуально, зависит от случая, чтобы вписывать это в какую-то стандартную концепцию. #полныйаджайл
Количество поздравлений с наступившим годом от телеграм-каналов просто умопомрачительное. Читать я их перестал где-то после третьего. А «Экстраполяция» от большинства каналов отличается тем, что очень любит и ценит вас, чтобы по-просту спамить бесполезным сообщениями или рекламой, например.
Так что, во-первых с Новым Годом вас, друзья мои. 🎄
А во-вторых — полезная ссылка. Можно сказать, свежачок с анализом современного джаваскрипта, сделанного на основе опроса разработчиков.
«Джаваскрипт ты можешь не любить, но уважать его обязан», как сказал классик.
https://medium.freecodecamp.org/i-just-asked-23-000-developers-what-they-think-of-javascript-heres-what-i-learned-9a06b61998fa
Так что, во-первых с Новым Годом вас, друзья мои. 🎄
А во-вторых — полезная ссылка. Можно сказать, свежачок с анализом современного джаваскрипта, сделанного на основе опроса разработчиков.
«Джаваскрипт ты можешь не любить, но уважать его обязан», как сказал классик.
https://medium.freecodecamp.org/i-just-asked-23-000-developers-what-they-think-of-javascript-heres-what-i-learned-9a06b61998fa
freeCodeCamp.org
I just asked 23,000 developers what they think of JavaScript. Here’s what I learned.
by Sacha Greif I just asked 23,000 developers what they think of JavaScript. Here’s what I learned. I recently published our results for the 2017 edition of the annual State of JavaScript survey, collected from over 23,000 developers. The results revealed…
Лайвхаки от Экстраполяции
Приложений для общения в телеграме существует не один десяток под разные платформы. И недостатки неофициальных клиентов сильно очевидны, чтобы их перечислять. Использовать официальные объективно выгоднее.
Так вот, под Макось существует два официальных клиента. Один ужасный кросплатформенный монстр. А второй — нативный красавец. Почему-то подавляющее большинство знакомых ставят себе кросплатформенного уродца, вместо быстрого и симпатичного удальца. Удаляйте чудище и ставьте себе принцессу: https://macos.telegram.org/
Под Айос официальных клиентов тоже два, но тут оба красавца. Приложение, которое ставят себе подавляющее большинство владельцев айфонов, безусловно на порядок лучше любых вайберов, скайпов и ватсапов, но по сравнению с «Telegram X» слегка медленновато и не имеет ночной темы. Качайте: https://itunes.apple.com/ru/app/telegram-x/id898228810?mt=8
Приложений для общения в телеграме существует не один десяток под разные платформы. И недостатки неофициальных клиентов сильно очевидны, чтобы их перечислять. Использовать официальные объективно выгоднее.
Так вот, под Макось существует два официальных клиента. Один ужасный кросплатформенный монстр. А второй — нативный красавец. Почему-то подавляющее большинство знакомых ставят себе кросплатформенного уродца, вместо быстрого и симпатичного удальца. Удаляйте чудище и ставьте себе принцессу: https://macos.telegram.org/
Под Айос официальных клиентов тоже два, но тут оба красавца. Приложение, которое ставят себе подавляющее большинство владельцев айфонов, безусловно на порядок лучше любых вайберов, скайпов и ватсапов, но по сравнению с «Telegram X» слегка медленновато и не имеет ночной темы. Качайте: https://itunes.apple.com/ru/app/telegram-x/id898228810?mt=8
Личным сообщением читатели (много читателей) подсказывают, что в основной айосный телеграм тоже добавили ночную тему. Так что это не повод переходить на «X». Возможно, судя по названию, владельцы последних-распоследних айфонов могут какое-то улучшение нового телеграма увидеть. Но это не точно.
А так в X-телеграме много полезных фич еще не имплементировали. Например геолокация в реальном времени еще отсутствует, количество непрочитанных сообщений пропадает далеко не сразу после прочтения с другого устройства, сохранение напечатанного текста работает не всегда. В общем, любители бета-версий должны быть довольны новым телеграмом. А я себе старый вернул. Что же до десктопной версии под макось, то там все стабильно — кроссплатформенное чудище и нативная красавица.
Ну не даются новостные заметки Экстраполяции, что тут поделаешь! Стоит отложить пост на пару дней, так уже старье, боян и уже неправда. Может, пригласить внештатного редактора для новостных заметок (🗣) или ну их к чертям, эти новости (😈)?
А так в X-телеграме много полезных фич еще не имплементировали. Например геолокация в реальном времени еще отсутствует, количество непрочитанных сообщений пропадает далеко не сразу после прочтения с другого устройства, сохранение напечатанного текста работает не всегда. В общем, любители бета-версий должны быть довольны новым телеграмом. А я себе старый вернул. Что же до десктопной версии под макось, то там все стабильно — кроссплатформенное чудище и нативная красавица.
Ну не даются новостные заметки Экстраполяции, что тут поделаешь! Стоит отложить пост на пару дней, так уже старье, боян и уже неправда. Может, пригласить внештатного редактора для новостных заметок (🗣) или ну их к чертям, эти новости (😈)?