Экстраполяция IT, страница 10, все посты канала

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

Скрипт для блокировки каналов написан. Распространите. Все проблемы, баги и новые фичи делаем через пулл реквесты, всё, как мы любим. github.com/fk-war-…channels

GitHub - fk-war-in-ukraine/report-telegram-channels

Contribute to fk-war-in-ukraine/report-telegram-channels development by creating an account on GitHub.

GitHub

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

Подскажите, пожалуйста, какой есть офлайн мессенджер рабочий? bridgefy на пикселе крашится, на айфоне никого не видит.

Ребята, есть кто там в районах потише и в состоянии программировать? > Нужен программист PYTHON. Есть огромные списки телеграм каналов проросейских ботов. На каждый из них нужно кидать репорт. Вручную это вечность. > В API методах телеги есть функция account.reportPeer#c5ba3d86 peer:InputPeer reason:ReportReason message:string = Bool; > Кто может написать Telegram БОТА, которая будет принимать в себя список телеграм каналов из текстового файла и автоматом кидать репорты на весь список (возможно выдать список обратно тех, которые не нашлись/уже заблокированы)

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

Ребята, как вы? Давайте устроим перекличку и слова поддержки в комментариях.

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

«Закон Мура гласит, что объём папки node_modules удваивается каждый новый релиз»

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

Синдром самозванца. Во-первых, специалист высокого уровня разбирается во всём, что более-менее в его компетенции. Это да. Во-вторых, таких результатов можно добиться только тогда, когда постоянно расширяешь область своей специализации и получаешь новый опыт. Как вывод из этих двух пунктов: чтобы становиться лучше, нужно всегда делать то, в чём ты разбираешься не очень хорошо. И тут-то и возникает этот синдром, ведь внезапно нужно делать не то, в чём разбираешься. Если вдруг оказывается, что синдром самозванца пропал, то это повод задуматься, не перестал ли ты развиваться как специалист. Но только главное не переборщить с новизной и не бросаться вообще в незнакомую среду и обязанности, а комбинировать существующий опыт и получение нового, чтобы синдром самозванца не перерос в паническую атаку самозванца с неизбежным выгоранием самозванца. Иными словами нужно всегда держать внутреннего самозванца в тонусе.

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

Обожаю читать вот такое, что в целом связано с программированием весьма посредственно (в данном случае это политика), но по сути технологично и стартапно по самое горло. Если в двух словах, у властей Индии есть специальное приложение, которое в пару кликов с помощью сети ботов позволяет выводить в тренды всё, что правительственной душе угодно и ещё и спамить и заниматься харассментом. Если вынести за скобочки политическую составляющую, то это прям квинтессенция корпоративного управления. Обычно же большие компании просто нанимают айти-отдел побольше, создают эксельки подлиннее и цепочку менеджеров по запутаннее, а тут отдельное автоматизированное приложение, лишенное человеческого фактора. https://thewire.in/tekfog/en/1.html

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

«Любая более-менее развитая технология неотличима от фреймворка». #dimoneverything

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

Я тут внезапно осознал, что программирование — это магия. Та самая магия, из книжек, когда можно сделать что-то такое, что выглядит в разы проще и эффективнее прямого влобного способа. Ну ладно, почти такая же магия, только не нарушающая закон сохранения энергии. И самое интересное, что это работает на всех уровнях абстракции. Ну, вот пишу я в специальном файлике resources :projects, а оно мне подготавливает целый набор урлов с правильными гетами, постами и патчами, которые указывают на специальные классы и методы в этих классах. Причем, если написать resource :project будет почти такое же самое, но, как говорит Василий Иваныч, есть один нюанс. И, конечно же, высшие маги знают что и как там происходит под капотом и умеют применить это заклинание куда более эффективно, дописав какой-то неочевидный параметр или используя метапрограммирование, но магия не перестаёт быть магией — одно простое заклинание делает то, что вручную делать сильно сложнее.

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

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



expect(client.phone).to eq(client.phone)

Увидев такое, я, сам того не замечая, прошёл все стадии знакомства с легаси: гнев, отрицание, желание переписать и попытки пофиксить. В итоге, обретя катарсис, я занялся тем, чем следовало бы заняться с самого начала — поиском причин появления вот такого вот странного теста. Сперва были отметены какие-либо разумные причины, вроде каких-то побочных эффектов вызова геттера — всё было так, как выглядело, обычный геттер, который так же обычно читается. Потом в ход пошла история изменений файла и сопуствующие изменения в коммите. Ну и, конечно же, коммит-каменты. Во-первых, хочу напомнить, что именно для вот таких вот случаев и нужно группировать изменения атомарно и давать внятные пояснения не того, что происходит в коммите, а того, зачем это происходит. Во-вторых очередной раз убедился, что скваш (squash) коммитов — это неудобно. В-третьих добавлю, что комментарии в гит-коммите должны быть самодостаточны. Комментарии, вроде Fixed issue CN-ERT-5553, наверное, помогают быстрее писать комментарии и быстрее принимать пулл реквесты, но совершенно теряют историческую ценность. Как вы понимаете, своим внутренним баг-трекером писатели кода делиться не собирались. В итоге дедуктивного расследования выяснилось, что в какой-то момент деньги стали заканчиваться быстрее, чем набор несделанных фич и приходилось на чём-то экономить. И экономить начали на времени разработки. Сначала тест появился, как следует, с внятной плоской проверкой, вроде eq('+380999999999’). Потом попросили писать номер в определённом формате. Добавив валидацию, оказалось, что создание объекта для теста выходит чуточку сложнее. В итоге сначала убрали все вольные создания объектов и заменили на системный фабричный подход и тут (внимание) упало несколько тестов, которые говорят, мол, у вас там какой-то непонятный международный формат, а у нас тут надо просто кучу девяток. И программист в спешке решал чему же должен быть равен сгенерированный случайный номер телефона по определённому формату. Оказалось, что номер телефона строго равен номеру телефона и больше ничему другому не равен. Просто удалить тест он, конечно же, не мог, потому что падающие метрики никому не нужны. Виноват ли этот программист? Определённо нет, по истории коммитов видно под каким давлением со стороны заказчиков и руководства приходилось исправлять неисправленное. Может быть, руководство аусорса как-то лучше могло себя показать? Вряд ли, счета по проекту внезапно грозили быть неоплаченными и нужно было срочно доделывать обещанное. Может быть, заказчику нужно быть дальновиднее? Тоже нет, ему просто выставляют счета и обещают фичи. Вот так вот, каждый действовал оптимальным для себя образом и в итоге получилось, что получилось.

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

У бота, через которого отправляются посты в «Экстраполяцию» всё меньше и меньше конкурентных преимуществ. Раньше были каменты в фрейме, сейчас они нативные. Раньше хотелось отложенных записей, телеграм это умеет сам. Теперь вот лайки завезли. Если честно, отношение двоякое. Сначала была твёрдая уверенность, что телеграмм — это такая себе платформа, где каждый может себе слепить то, чего хочется, с кнопками, реакциями и вообще всем, чем хочешь. А сейчас всё больше ощущения очередной реинкарнации ЖЖ. Не то, чтобы это было плохо. Уверен, создатели телеграм тоже задумывали его, как платформу, а потом пришли настоящие пользователи и захотели вот это вот всё.

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

«Эти все паттерны-шматерны, софт-скиллы и знания третьего ангулара это, конечно, хорошо, но самый важный инструмент, который есть у разработчика — это возможность принимать решения. И брать за них ответственность, само собой»

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

Самое интересное занятие при разработке — придумывать полезные функции.

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

Сегодня опять #экстрастереотипы и в этот раз поговорим о Бритве Оккама. На всякий случай сформулирую: «Многообразие не следует предполагать без необходимости». Или другими словами это о том, какому из нескольких вариантов объяснения нужно отдать предпочтение — тому, который проще. Во-первых, попрошу заметить, не Окка́ма, а О́ккама. Но это так, литературная фигня. Ещё вообще не важно, но тоже стоит упомянуть, что сам Уильям Оккама ни о какой бритве знать не знал, это просто его именем назвали принцип сильно позже. Во-вторых, это не никакой не закон, а всего-лишь презумпция. Это значит, что основывать свой выбор только этим принципом никак нельзя. Бритва может помочь сэкономить время, выбрав какую гипотезу следует проверить раньше других. Не надо вот этих «давайте в базе две таблички, а не три сделаем, потому что Бритва Оккама», да? Может две, а может три, тут надо проверять. И да, логичней сначала проверить две. Во-третьих и самых главных, нельзя сравнивать два абстрактрых объяснения между собой этим принципом. К двум утверждениям «давайте данные Монго будем складывать» и «давайте лучше в Постгрес и рядом Редис ещё развернём» Бритва применима? Подсказывает ли Оккама нам, что лучше начать с Монго, вместо Постгреса с Редисом, потому что там два, а тут один? Нет! Из двух утверждений «А вместе с Б» и «только В» вообще нельзя делать никаких выводов, потому как совершенно нельзя определить что из этого проще. Вполне может оказаться, что А+Б выйдет сильно проще, чем В. А может и не выйдет, Оккама тут бессилен вам помочь, давайте уж как-нибудь сами. А вот то, о чём Бритва Оккама действительно говорит, что если что-то можно объяснить с помощью утверждений А и Б или только с помощью А, то стоит отдать предпочтение только А. Из двух утверждений «давайте обойдёмся только постгресом» или «давайте рядом с постгресом ещё и редис лупанём», лучше сначала потратить силы и попробовать обойтись только постгресом, а потом пробовать что-то рядом запускать.

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

Мне тут недавно рассказали в чём кардинальное преимущество сеньора перед вон теми вот остальными милордами и сэрами или как там они называются. Говорят, что сеньор разработчик точно знает как надо делать. Мол, учитывает все подводные камни, возможные пути развития кода и выбирает самый оптимальный способ написать код вот прям здесь и прям сейчас. Так-то придраться к этому факту можно, конечно, уж слишком он субъективен. Но мне подумалось, что главная фишка опытного разработчика в том, что он точно знает как его код будут переписывать потомки и делает так, чтобы после переписывания его кода он стал идеальным. Такая вот мета-разработка выходит.

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

Ваше следующее задание — оцентровать <div> по вертикали.

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

Внезапно оказалось, что четверть всего написанного мною кода пишет нейронный дополнятор.

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

К рекламе на Фейсбуке зацепил комментарий. Реклама сама об обучении ребёнка программированию и нацелена на американских родителей. "Unless and until corporations stop sending these jobs overseas, there will be NO opportunities for "coding" in America. I personally know a LOT of people who were replaced by overseas contractors - along with engineers, paralegals, accountants, customer service - just to name a few." Ну то есть, человек не советует в Америке входить в айти потому, что там уже мы. Как-то не приходилось задумываться, что мы для них проблема. #dimoneverything