Страница телеграм канала Экстраполяция IT

itextrapolation logo

Экстраполяция IT

3459 подписчиков

Канал об IT в целом и о программировании в частности. Для обратной связи пишите @aratak Платной рекламы на канале нет, взаимных пиаров тоже, любителей объеденяться в репост-кланы в бан. фейсбук: fb.me/alexey.osipenko твиттер: twitter.com/alexeyosipenko


Входит в категории: Технологии
Экстраполяция IT
10.02.2019 12:02
Наверняка интересующиеся это уже видели, 10 месяцев прошло в конце-то концов, но коммит очень хорош. https://github.com/reduxjs/redux/commit/9276ff0af6400633d6731b15fed6e70c3561887e
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
08.02.2019 12:02
Последний пост в цикле #cssэкстраполяция и он будет про попиксельную верстку. И сначала у меня несколько утверждений. Во-первых, дизайнеры никогда не показывают в макетах все возможные виды и странички проекты. Это логично, понятно и правильно. Дизайнер не в состоянии перебрать все возможные сочетания всех возможных отображений на всех страничках. Во-вторых, приложение никогда не стоит на месте, и новые фичи и отображения могут появляться очень быстро. Приходится верстать поверх старого, уже наверстанного. В-третьих, дизайнера не заботит количество пикселей слева и справа от блока. Когда ему надо поставить блок посередине, он берет мышку и тянет блок в середину. Если слева будет 56 пикселей, а справа 57, то для дизайнера это посередине. Учитывая эти три штуки, требовать от верстальщика пиксельперфект — путь к усложнению работы и ухудшению кода. Единственный вариант, когда попиксельное сравнение с макетом выгодно, когда верстальщик не хочет отвечать за результат и пытается переложить ответственность на дизайнера. Или не может. Часто такой способ взаимодействия выбирают, когда работу ведёт группа фрилансеров отдельно друг от друга. Оправдывается это тем, что это единственный способ формально принять работы и у дизайнера и у верстальщика. Итого: 1. Дизайнеру нужно рисовать больше макетов, чтобы было с чем сравнивать попиксельно. 2. Верстальщик превращается в “psd2html converter” и от него требуют перестать задумываться над смыслом свёрстанного. Мол, ты верстай, а думать другие будут. 3. Пропадает возможность исправить логическую ошибку на этапе верстки. 4. Умным и творческим или просто амбициозным людям нет никакого резона оставаться просто верстальщиками. И, конечно же, чтобы не сравнивать попиксельно, верстальщик должен быть чуточку дизайнером, чтобы видеть в макетах идею, а не реализацию.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
05.02.2019 12:02
Буквально вчера в разговоре сформулировали очень хорошую аналогию с вёрсткой. Она прям настолько хороша, что нравится мне при всей нелюбви к аналогиям в целом. Итак, физика (наука). У ученых-физиков есть только один внятный способ выводить законы и находить формулы нашей вселенной — они наблюдают за экспериментами и различными ситуациями, придумывают формулы и сравнивают их с результатами экспериментов. Все. Иногда формулы работают хорошо, пока не будет новых наблюдений, другими словами, пока отдел дизайнеров не пришлёт новый макет. Тогда старые формулы признаются негодными и придумываются новые. Или старые формулы вдруг получают новые исключения. Потом исключения из исключений, потом формулы, противоречащие друг другу, потом исключения из противоречий и так далее. В какой-то момент, набор формул признаётся говном и считается, что они как бы формально описывают происходящее вокруг, но делают это плохо, и находится пачка формул, которая описывает больше различных ситуаций и делает это меньшим количеством правил и исключений. Итак, как физики определяют какая из альтернатив лучшая: там, где меньше формул и меньше исключений из правил, там и лучше. Та альтернатива лучше, которая в состоянии описать все эксперименты, которые не наблюдались в процессе составления формул. Если вам надо сверстать новую страничку с какими-то новыми доселе неведомыми сущностями и при этом не пришлось выписывать новую пачку css-правил, то у вас в стилях все хорошо. #cssэкстраполяция
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
22.01.2019 17:01
В продолжение прошлой заметки, сразу несколько читателей спросили о микроменеджменте задач, типа, давайте разбивать задачи на подзадачи так, чтобы каждый пулл реквест таки соответствовал хотя бы подзадаче и будет все чики-пики. Один читатель даже задал этот вопрос и потом его почему-то тут же удалил, а ответить ему я не успел. И кажется, что проблема в подзадачах далеко не в том, что пулл реквесты вдруг будут совместимы с подзадачами. Беда в том, что подзадачи вдруг считают чем-то таким, о чем можно рассуждать на уровне управления проектом. Что же, давайте разберемся. 1. Даже сам разработчик не знает весь набор шагов для реализации задуманного, не говоря уже о каком-то там менеджере. Прям, как в шахматах, есть вполне конкретный план, но с закрытыми глазами его выполнять нельзя и обязательно нужно пересматривать его после каждого изменения. 2. Очень важно разобраться с формулировкой задач. Задачи, вроде «обновить библиотеку А с версии 1.0.3 до 1.0.5» быть не может, ведь это никому не интересно, ни разработчику, ни менеджеру, ни управляющему. Все задачи должны быть сформулированы исключительно с точки зрения пользователя системы. В этом смысле очень нравится термин «user story» (не знаю как это правильно перевести, не потеряв смысл), где сразу становится понятно что же будет являться той самой историей пользователя, а что не будет. 3. Подзадачи действительно могут быть сугубо техническими, и даже про обновление чего-то там на что-то там. Но с точки взаимодействия между людьми в проекте подзадач вообще не существует. Задачи и только! 4. Задачу, конечно же, очень полезно разбить на отдельные, более мелкие задачи, но только при условии смысла в каждой отдельной задаче для пользователя системы.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
21.01.2019 13:01
Внезапная заметка о пулл реквестах. Ошибочно считать, что фича должна быть сделана за один пулл реквест. Или, если подходить формально, за наименьшее количество пулл реквестов. С такими пулл реквестами искать ошибки и причины их появления становится значительно тяжелей. В добавок совершенно непонятно на какой стадии находится разработка текущей фичи. Почти готова ли она или там только начало — точно не знает даже разработчик этой самой фичи. Кроме того, гит-конфликты будут возникать на каждом шагу и будут настолько огромны, что будут тянуть на небольшую такую задачку с абсурдным названием «пытаемся смержить текущий мастер в мою ветку на 100+ коммитов» с оценкой часов в пять. Ну, и вишенкой на торте будет полностью парализованный git bisect. При марафонском пулл реквесте с мириадой коммитов с уверенностью можно будет утверждать, что «баг где-то там, между двумя мастерами». Не люблю проводить аналогии, но тут попробую. Разработка конкретной фичи должна быть похожа на шахматную задачу, где каждый отдельный ход — отдельный пулл реквест. Без пояснений не совсем понятно зачем ладьей нужно было ходить именно сюда, но ситуация на доске в целом понятна. В этой аналогии хорошо то, что пулл реквесты от остальных членов команды похожи на ходы противника. Этой самой ладьей нужно ходить так, чтобы не было мата (в прямом и переносном смысле) и рассчитывать, что оппоненты в партии могут сделать совершенно неожиданный ход. Пулл реквесты должны быть как можно меньше и как можно атомарней и тогда все будут счастливы. А фича может состоять из кучи пулл реквестов, идущих не обязательно подряд.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
06.01.2019 12:01
Удивительно, отвечая об организации css, большинство рассказывают, что принципиально не используют css-фреймворки. Мол, это неудобно, громоздко, много лишнего, многого не хватает и слишком негибко. Да, вроде все варианты из ответов перечислил. А секрет в том, чтобы в каждом отдельном проекте писать свой собственный css-фреймворк. И в этом вся сложность написания css как бы. И всякий существующий фреймворк — лишь удобный способ начать это делать, ведь самое ценное, что он даёт — принципы формирования папочек-файликов, названий и всякого такого. Если вдруг так оказалось, что верстальщик в состоянии справиться с организацией стилей без сторонней помощи, то фреймворк действительно использовать не надо.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
28.12.2018 13:12
Сегодня просто цитата из рабочей переписки: «Я год работал над собой, прежде чем смог сменить чувство, что я подвёл чьи-то ожидания, не сделав задачу в срок, на чувство "какой дебил написал здесь "два часа".»
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
17.12.2018 12:12
Как и ожидалось, ответов по поводу организации css в проектах было много. Тех, которые будут публиковаться — всего парочка и начнём с самого крутого. Прислал его Андрей, который практически уже соавтор канала. Тырим подходы у этих парней: https://innoq.style/. У них там Atomic Design (общая философия для делелния на компоненты)+ ITCSS (структура организации стилей, где они раскладываются по слоям. Там находится место и всяким миксинам/тулзам, которые даже не генерируют цсс и всяким ресетам/нормалайзам) + BEM (для синтаксиса и правил для определения классов). В последнем проекте мы заменили BEM на bliss-css, что слегка поменяло синтаксис классов, в некоторые места принесло чуток больше ясности, а в некоторые конфликты с ITCSS. В чем были конфликты не вспомню, но они были мелкими и вполне нормально разруливаемыми и документируемыми. В этом последнем проекте мы действительно заморочились и сделали все правильно: https://visdeal.gitlab.io/ А вообще чувствую себя старпером, когда на собеседованиях начинаю спрашивать подобные штуки. Никто внятно не отвечает на такие вопросы. Народ или не писал приложений, которые нужно было бы поддерживать в течении достаточно длительного времени и в котором начинали бы выползать косяки изначальной организации стилей, или сразу начинал использовать какие-нибудь styled components, которые в принципе исключают проблемы с нарушением изоляции.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
16.12.2018 12:12
Недавно мы проводили опрос о проектном инструменте и вот результаты. Как и предполагалось, большинство используют Джиру и подавляющее большинство не в восторге. Ну, типа работает и ладно. Из внезапного, очень много опрошенных говорят о том, что в проектном инструменте важна скорость работы. Если честно, я думал, что большинству плевать на отзывчивость интерфейсов или эту самую отзывчивость большинство не замечает. Но, видимо, основной инструмент настолько тормознутый, что это прям бесит. Подробнее в аккуратно написанной статье: https://riter.co/blog/results-of-our-survey-on-project-management-tools
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
12.12.2018 12:12
С css сплошная беда. Файлики стилей пухнут пропорционально добавляемым фичам, а старые правила менять все опасней и опасней. Проще новые рядом прописать. Проект большой, кто его знает где может все сломаться в каком-нибудь дремучем Нетскейп Навигаторе. Ну, или что вы там сегодня поддерживаете. Сообщество стонет, сообщество пытается решить проблему, как умеет. И тут-то и начинается жесть. Дело в том, что современные верстальщики очень быстро учатся программировать (и это очень хорошо) и пытаются решать проблемы вёрстки патернами программирования. Это когда: — Джаваскриптовые компоненты стили за собой тянут. Становится только хуже, ведь проблема перекладывается с больной головы на безнадежно больную. Типа, пусть джаваскриптизеры дублируют, наши руки чисты. — Начинают использовать css-фреймворки. Ничего не меняется, а редактировать стили фреймворков ещё страшнее. — Ищут спасения в генерации стилей всякими sass или less. Становится неочевидно хуже, ведь писать приходится меньше букв, а код все так же страшно менять. А верстка, хоть и идёт ноздря в ноздрю с джаваскриптом, но подходы любит совершенно другие. Расскажите мне, дорогие друзья, как вы боретесь с постоянно растущей и пухнущей таблицей стилей. Лучше всего личным сообщением (@aratak) и с хештегом, чтобы не потерять (#cssэкстраполяция). Мне очень интересно и, уверен, многим тоже.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
10.12.2018 12:12
Разработка очень похожа на эдакие шахматы, где соперник разработчика — юзер. Ну, или тот, кто фичи заказывает. Легко предположить, что вот этот вот новый кусок кода заставит пользователей что-то такое делать, что породит новый запрос на новую фичу. Если не хочется той новой фичи, думайте лучше над текущей имплементацией. Отличие от шахмат, конечно же есть. Например, в шахматах сам процесс хода одинаково сложный как для ферзя, так и для ладьи. В разработке у каждого хода есть своя цена. Ещё шахматы — игра на двоих, а в разработке очень часто нужно играть против нескольких соперников. Основной принцип все же соблюдается — необходимо думать на несколько ходов вперёд.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
25.11.2018 12:11
Наверняка вы знаете про существование ложноположительных и ложноотрицательных результатов. Ну, когда система говорит да, а на самом деле нет и наоборот. При проектировании систем важно определиться с тем, какие результаты допускать можно, а какие нельзя. Прочувствовать это легко на примере спама. Какой результат предпочтительней, когда нормальное письмо попадает в спам или когда спам во входящие? Ладно со спамом, как насчет банков и их технологических решений? Совершаемый платеж по карте пропустить или заблокировать решает система все так же полагаясь на то, что лучше заблокировать нормальный платеж, чем пропустить воровство. Типа, ложноотрицательные результаты недопустимы, а с ложноположительными можно даже жить. И в некоторых системах выявить такие вот нестандартные результаты очень тяжело. И поэтому внедрение технологий происходит медленнее, чем нам бы хотелось.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
23.11.2018 12:11
Очень легко распознать протекающую абстракцию в чужом коде, который используешь. Ну, типа, знания об внутреннем устройстве библиотеки отсутствует и работа ведётся на уровне описанного в документации интерфейса. Протекать абстракция начинает, когда необходимо знать как оно ведёт себя внутри. Тяжело обнаружить протекающую абстракцию в текущем проекте. Во-первых знания о работе приложения получаются только с помощью изучения кода. Во-вторых разработчик приложения обязан знать как оно себя ведёт внутри.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
20.11.2018 12:11
Какой бы сложности не было бы приложение, какое бы оно не было бы идеальное, принципиально в коде будет только две штуки: правила и исключения из правил. И кроме того, что важно минимизировать количество исключений, не менее важно ещё и минимизировать количество пересечений действия разных правил.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме


Экстраполяция IT
17.11.2018 12:11
Ребята, экстраполяция, конечно, экстраполяцией, она никуда не делась и все по-старому. Но я буду рад вас видеть еще и в соцсетях в традиционном смысле этого слова. Например, в фейсбуке (https://www.facebook.com/alexey.osipenko) или в инстаграм (https://www.instagram.com/aratak/). Программирования там мало, потому как оно все тут сосредоточено. А вот непрограммирование в экстраполяцию не попадает, а попадает все туда. В общем, добро пожаловать.
Читать

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме