2453
Канал об IT в целом и о программировании в частности. На канале объявлено военное положение и поэтому по вопросам рекламы пишите: @aratak, а деньги отправляйте сюда: https://send.monobank.ua/jar/97f7LwGQJF
Прибор уже у пограничников. Суммарно вышел чуть больше 144 тыщ. 44 тысячи удалось собрать этим публичным сбором, остальное собрали тесным кругом друзей, за что большое спасибо всем учавствовавшим.
Читать полностью…
Не уверен, что хочу разбираться что тут происходит, но это React 19 вместе с Typescript 6.
Читать полностью…
Господа рубисты и рельсовики-зайтейники. А накидайте-ка мне, пожалуйста, в комментарии или в личные сообщения блоги, которые вы читаете по теме. И ещё репозитории (вроде rails/rails или `jekyll/jekyll`), за которыми обязан следить каждый уважающий себя рубист. Может, какая рассылка есть ещё? Тоже подойдёт. Очевидные и само собой разумеющиеся тоже кидайте, не стесняйтесь.
Мы тут штуку одну делаем, надеюсь, в итоге будет полезна всем. Спасибо.
Главная ошибка в разговорах о повышении зарплаты — это расхваливание своих бывших заслуг. Логика работодателя вполне простая: сотрудник делает своё дело, в конце месяца получает за это деньги. И так каждый месяц. Договорённость о зарплате — это обещание заплатить столько-то денег, когда сотрудник сделает столько-то вот такой вот работы. Это не делёж награбленного на приратском судне, где сильные и авторитетные пираты получат больше, это не признание в любви к сотруднику, где покупают бриллианты «если ты меня любишь». Это всего лишь договорённость об обмене труда на деньги.
Из этого естественным образом вытекает очень простое следствие.
Работодатель согласен заплатить в следующих месяцах больше, если это выгоднее, чем искать нового сотрудника. Конечно, учитывая все риски долго его искать, найти не того, какое-то время вводить новичка в курс дела.
Скажем, зарплата абстрактного сотрудника $100 и он хочет 10% повышения. Работодатель знает, что найти замену можно за месяц и еще месяц уйдет, чтобы ввести в курс дела нового сотрудника. Получается, уволить того, кто есть, будет стоить $200, а повысить ему зарплату будет стоить $120 в год. Руководству, выгоднее повысить зарплату, чем лишиться имеющегося сотрудника.
Конечно же, в этой очень простой формуле куча неучтённых факторов, но речь сейчас не о способе рассчитать повышение зарплаты, а об акцентах. Прошлые заслуги — дело прошлых зарплат, а не будущих.
Как вывод, при любых разговорах о повышении зарплат или увеличении ответстветнности, речь должна идти только о том, что будет. Конечно, в пример можно приводить то, что было раньше, но только лишь в качестве доказательств, что в будущем будет ещё лучше. Экстраполируйте, короче.
Ребята, которым мы помогаем, передают привет и немного сувенирных шевронов для тех, кто регулярно помогает. Шевроны я уже почти всем отправил почтой.
Героям слава.
Читая ваши варианты использования ИИ в работе, вспоминается классика.
«Пап, а если ИИ будет делать за тебя половину работы, значит ты будешь работать в два раза меньше? Да, пап? Почему ты плачешь, папа?»
Так, кажется, уже вообще все используют gpt не только, чтобы быстро узнать в каком возрасте Тарас Григорьевич «пас телята за селом», сгенерировать кусочек кода или узнать сколько лет длилась столетняя война.
Есть какие-нибудь удачные попытки использовать gpt на корпоративном уровне? Кто-то уже успел встроить его в бизнес-процессы? Не стесняйтесь, делитесь. Если уж сильно стесняетесь разболтать корпоративную тайну, разбалтывайте в личку мне.
Есть у меня манера такая, из-за которой я постоянно забочусь о будущем гипотетическом вертикальном масштабировании приложения ещё на этапе git init. Буквально везде переживаю, чтобы можно было расширить, засунуть и скейлить новую связь, сделать из отношений один-к-одному отношения многие-ко-многим, всунуть мультипрофили, переключение контекстов и всякое такое. Прям со старта, когда нужно просто добавить одну табличку в базу и модельку создать, у меня на ровном месте появляются company_id, author_id и вот это вот всё такое подобное. С точки зрения энтерпрайза это, наверное, неплохо, но вот в стартапном подходе это сильно мешает ускорится и сделать релиз уже к вечеру.
И что с этим делать и нужно ли вообще с этим что-то делать я совершенно не представляю. С одной стороны это сильно тормозит прототипирование. С другой — прототип легко и без дополнительных костылей разрастается в энтерпрайз. В общем, буриданова дилемма никак не иначе.
Есть очень хороший косвенный признак масштаба компании, с которой вы общаетесь. Ну вот приходит вам емейл с почтового ящика john@example.com. Сразу видно, что это — маленькая компания, скорее всего уровня стартапа, даже если содержимое письма говорит об обратном.
Дело в том, что при при определённом пороге красивые короткие имена заканчиваются и любое правило коротких имён перестаёт действовать. Я знаком с правилами выбора емейлов в компании по никнеймам, по первым буквам имени и фамилии, только по именам и вообще хаотические правила «какой емейл хочешь такой и заведём». Но все эти правила нарушаются при первом же дублировании. Можно, конечно, сопротивлятся до последнего и добавлять букву второго имени и придумывать новые псевдонимы, но рано или поздно емейлы приходят к универсальному стандарту имя.фамилия@exampe.com, а вон то старьё в виде никнеймов и аббревиатур становится алиасами, которыми лучше не пользоваться.
Следующая стадия размера компании — обезличенные емейлы, вроде hr@exampe.com или ceo@example.com. Там тяжело сказать о размере, но от таких емейлов тоже рано или поздно отказываются в качестве исходящей почты и оставляют только в качестве входящей рассылки.
Небольшой волонтёрский апдейт.
Две отремонтированные машины (вторую без номеров или лиц в галерее я не смог найти, сорян) и ещё один купленный Пежо уже у ребят. Пежо уже успел совсем чуть-чуть побывать в бою и уже снова ремонтируется, но это не беда, — отремонтируем и эту.
А ещё удалось приобрести и отправить подразделению пограничной службы «Шквал» прибор ночного видения для водителя. А ребята в ответ передали благодарность и привет всем причастным.
Там все к чему-то активно готовится, ума не приложу к чему конкретно, даже идей никаких нет. Ну и пусть готовятся, наше дело помогать им со всех ног и рук, а не спрашивать «к чему» или «когда уже», правда ведь?
🫡
Лайвхаки от Экстраполяции
Приложений для общения в телеграме существует не один десяток под разные платформы. И недостатки неофициальных клиентов сильно очевидны, чтобы их перечислять. Использовать официальные объективно выгоднее.
Так вот, под Макось существует два официальных клиента. Один ужасный кросплатформенный монстр. А второй — нативный красавец. Почему-то подавляющее большинство знакомых ставят себе кросплатформенного уродца, вместо быстрого и симпатичного удальца. Удаляйте чудище и ставьте себе принцессу: https://macos.telegram.org/
Под Айос официальных клиентов тоже два, но тут оба красавца. Приложение, которое ставят себе подавляющее большинство владельцев айфонов, безусловно на порядок лучше любых вайберов, скайпов и ватсапов, но по сравнению с «Telegram X» слегка медленновато и не имеет ночной темы. Качайте: https://itunes.apple.com/ru/app/telegram-x/id898228810?mt=8
На просторах интернета обнаружилась вот такая вот картинка, по стандартному шаблону мема. Сначала показалось, что несмешная. Потом показалась смешной, потом показалась слишком философской.
Действительно, многие ругают излишнюю бюрократию управления проектов, а предложить что-то стоящее очень тяжело и сильно индивидуально, зависит от случая, чтобы вписывать это в какую-то стандартную концепцию. #полныйаджайл
Проклятые кастомные селекты.
Когда дизайн требует чего-то этакого от инпутов, верстальщики приседают в шпагате и делают довольно сумасшедшие вещи, типа картинки внутри инпута, но оставляют тег <input>. Но если появляются стили для выпадающего списка, тег <select> и его друзья <option> отправляются на помойку и вылезают <div> и джаваскрипт. Ну не пускают браузеры даже в распоследнем html/css кастомизировать селекты. Как же это печалит!
Стандартный селект прекрасен, он закрывается по Esc, он открывается по Cmd+вниз, в нём работает поиск (откройте селект и начните печатать), и ничего из этого ваши кастомные селекты в большинстве своём делать не умеют. Просто потому, что до этого не доходят руки у разрабатывающего этот компонент верстальщика.
Конечно, есть удачные решения, вроде бутстраповского кастомного селекта, джикверишного селекта и аналогичной реактджс-компоненты знаменитой. Но даже в этих случаях количество протекающих абстракций не ноль, а просто меньше, чем в остальных случаях. Если вам кажется, что вы знаете контрпример, в котором набор дивов ведет себя ну прям как селект точь-в-точь и никаких абстракций не протекает, то тут же вспомните об автозаполнении форм в браузерах или о длинных выпадающих списках и невысоких браузерных окнах (как на картинке).
К слову, когда браузеры были еще маленькими, эксплорер только мечтал о седьмой версии и хрома вообще не существовало, селекты были еще более независимыми. Некоторые браузеры, видимо в силу каких-то внутренних ограничений, отказывались реализовывать выпадающие списки стандартными способами и в ход шли костыли. Такие топорные дубовые неотшлифованные тяжелые костыли. Никакой речи о дополнительных стилях к селекту вообще не шло, там проблемы были намного серьезнее. Например, никакой див с абсолютным позиционированием и с увеличенным z-индексом не мог быть выше селект-инпута просто потому, что выпадающий список не являлся частью документа. Все селекты рендерились отдельно от всего документа и, собственно, поверх документа. Если вдруг хотелось сделать что-то вроде модального окна, то дополнительным джаваскриптом, при открытии любого модального див-элемента, всем выпадающим спискам на странице делался ниндзя-прием в виде 'visibility: hidden'. Еще можно было заметить на тормозящих компьютерах, что расчет позиции селекта на странице слегка отставал при скроллировании страницы. Селект немного позже рассчитывал свою позицию, чем это делала сама страница и перемещался с легким запозданием.
Очень хороший пример костыля в рубрику #айтермин.
Лайвхаки от экстраполяции.
Поразительно, насколько действие капслока по-умолчанию бесполезное. В дополнение эта клавиша считается клавишей модификации, и поэтому не может быть использована для чего-нибудь полезного без комбинации с другими кнопками. Именно по этой причине переключение языка с помощью ctrl+shift на макоси невозможна. С точки зрения системы никакая кнопка нажата не была, а были лишь зажаты клавиши модификации.
Самая, на мой взгляд, удобная функция на кнопке caps lock — переключение языков. В старых системах это решалось сторонними программами, где на уровне драйверов клавиатуры клавиша caps lock вдруг становилась какой-нибудь клавишей 'f15', но в последних версиях операционной системы это работать перестало.
Вместо этого появилась встроенная в систему возможность переключать язык по капслоку. Прелесть будет состоять в том, что можно оставить старое-доброе 'cmd+space' для переключения и в дополнение к нему — 'caps lock'. И плавно привыкать к капслоку.
Разнообразные формулировки говнокода сходятся в одном субъективном критерии — это когда плохо. Ну, то есть, трудно понять, трудно сопровождать, плохо написано, легко нечаянно сломать, некрасиво. Самое красивое определение этого термина — код без структуры или с большим количеством исключений из набора правил, принятым текущей структурой. Но с ним и вопроса особого нет, вопрос с костылём поинтереснее.
Костыль — частично пересекающееся с этим понятие, как на диаграммах венна, не весь говнокод — костыль и не любой костыль — говнокод, хотя последнее встречается пореже. Костыль — это когда что-то используется не по прямому назначению, а случайно, сайдэффектом. То есть, когда ты читаешь код, некоторое время его перевариваешь, понимаешь, почему это работает и восхищённый чужой изворотливостью крутишь головой. Или когда ты пишешь код, в определённый момент весело говоришь «о, так оно сейчас вот так заработает!» добиваешь парой слов, запускаешь и правда работает, а ты хитро хихикаешь.
Известный любому программисту термин "багофича" — это тоже о костыле. Только не сама багофича, а вот когда есть баг, а ты его в коде используешь как фичу. Частный случай костыля.
#айтермин
Пару месяцев назад удалось купить прибор ночного видения для подразделения пограничников «Шквал». Вот, показывают как он работает и говорят, что тяжело переоценить его полезность.
Просят ещё. Не хватает приблизительно тыщ 70. Спасибо за помощь.
https://send.monobank.ua/jar/8zAeCbuMw1
Оказывается, абсурдность идеи, что у ИИ нет души и он не может писать проповеди не для всех верующих очевидна. И в Германии в протестанской церкви провернули такую штуку, как ИИ-службу.
Хотя мне почему-то кажется, что пастор просто решил схалявить и не писать лонгридов.
Хлопці передають нам вітання ❤️. Дякую усім, хто зі мною допомагає цим бравим козакам. А хто ще не допомагає, але дуже хоче, то у опису до каналу є посилання на банку.
Слава Україні.
Делюсь мудростью общения с GPT. Мне нужно составить такой промпт, чтобы тот, через апи запрашивал у модели нужные мне данные в нужном формате. Естесственно, вариантов составления куча, нюансов тоже.
После того, как я пишу приблизительный такой промпт, я иду к самой GPT и предлагаю ей улучшить сам запрос. Мол, вот тебе запросик составил, как сделать его эффективнее и лучше, а?
Here is my prompt to the GPT3.5 which should generate a structured data in the response. Can you improve that?
{{{PROMPT_HERE}}}
Your prompt is already detailed and clear, but there's always room for some improvement. Here's a refined version:
{{{RESPONSE}}}
Why the sentence from your prompt "{{part _of_the_prompt}}." is better than my option "{{part _of_the_prompt}}."?
Опишу штуку, от которой я сильно прусь и которая была нами реализована.
В рельсах почти во всех таблицах в базе есть два поля updated_at и created_at с соответствующими значениями. Поля полезные, информативные. Однажды я задался целью держать эти поля актуальными, ну там бизнес-логика такого требовала. Чтобы когда создавался новый коментарий у задачи, чтобы updated_at поле обновлялось текущей датой. Вроде бы, задача для рельсовика вообще плёвая, toch: true дописал в нужном месте и делов-то.
Потом началось протекание абстракций. Сначала захотелось рекурсивного обновления. Чтобы у таблицы-дедушки обновлялось поле, если внук создаётся. Такой вот рекурсивный touch: true, который вообще-то так и работает. Во-вторых, промежуточные (torugh) таблицы игнорируются фреймворком. Ну вот есть у тебя companies, projects, comments и ты создаёшь companies.comments.create и хотелось бы, чтобы и у соответствующего и проекта и компании updated_at обновлялся, но нет. Ещё каждое обновление updatedat в каждой таблице — это отдельный запрос. В общем, фигня, как всегда.
И мы тогда добавили две вещи.
1. Значение по-умолчанию в таблице `createdat поставили в CURRENT_TIMESTAMP
2. Триггер таблицам, которые по всем foreignkey проходятся и там UPDATE updated_at делают соовтетсвующим записям в соседних таблицах.
Получилась красота неимоверная. Теперь никаких touch: true, а все записи в базе всегда в актуальных состояниях даже когда данные прямым sql-запросом обновляются.
«Кобзар» із віршем «мені сімнадцятий минало, я пас телята за селом» була опублікована, коли Тарасу Григоровичу було 23 роки. Столітня війна тривала 116 років. У «Пташиному молоці» немає молока птахів, а у крабових паличках немає мʼяса крабів.
На такі чи подібні цим питання не можна відповісти без двох властивостей ШІ: контексту та додаткових знань. Шо ви як маленькі, їй-богу.
Один из самых показательных и любимых «усложнений» в коде — это минимизация вызова методов на классе. Нет, не вообще вызовов, а тех, которые возвращают данные. Например, вместо того, чтобы на уровне контроллера написать Project.find(params[:id]) у меня появляется конструкция current_user.available_projects.find(params[:id]), где available_projects будет методом в классе User с приблизительно следующей реализацией:
def available_projects
Project.all
end
«Навчайся за донат» — проєкт на підтримку ЗСУ від громадської організації Демократична Сокира! В межах ініціативи слухачі опановують професію DevOps-інженера в обмін на донати війську. 20 травня стартує навчання третього потоку онлайн-курсу, який викладає технічний директор і співзасновник Tucha Володимир Мельник.
Під час практичних занять учасники дізнаються, як працювати з Docker, Kubernetes, Helm, GitLab, Ansible та іншими додатковими сервісами, які можна розгортати в кластерах Kubernetes. Загалом курс передбачає не менше 15 вебінарів у Zoom, кожен з яких триває щонайменше 2 години.
Докладна програма та деталі проведення курсу — за посиланням.
За кожну лекцію слухачі переказують 30.00 USD на рахунок фонду, які йдуть на закупівлю амуніції, військової форми, техніки, засобів тактичної медицини та іншого необхідного приладдя. Наразі завдяки проведенню DevOps-курсів зокрема зібрано понад 1 200 000 грн на потреби війська: авто для підрозділу ППО, квадрокоптери, прилади нічного бачення, портативні зарядні станції, спальники, тактичні рукавиці, купа засобів тактичної медицини тощо.
Запрошуємо стати слухачами нового потоку всіх, хто бажає розвиватися у DevOps-галузі та зробити свій внесок у наближення перемоги! Щоб приєднатися, заповніть невеличку анкету.
#волонтерство на правах реклами.
Попробую публично апеллировать Вове Рожкову и его мысли, что названия фундаментальных штук, вроде микросервисов должны быть максимально понятными по содержанию и не нужно придумывать красивых новых слов для всего подряд. Вова называет такие названия «кринжовыми» и избегает их.
Безусловно, название должно отражать суть происходящего, это даже не обсуждается. А придумывать новые слова или новые значения нужно для тех штук, которым нет удобного слова или словосочетания. Например, был себе джаваскрипт такой, существовал, а потом у него появилась особого вида функция, которая асинхронно вызывает другую функцию. Ну есть же термин «функция высшего порядка» там, а у нас тут асинхронный вызов функций. Ну назови ты её «async higher-order function» и всё. Зачем же придумывать для неё отдельное слово «Promise»? Но вот придумали, потому что этот вот промис планировался, как особого вида функция и что это не просто «async higher-order function».
А дело в том, что так в человеческих языках и придумываются новые слова и новые значения. Для тех штук, которые долго объяснять по сути и длинно читать по составу люди находят красивые и лаконичные слова, чтобы быстро коммуницировать друг с другом. Конечно, важно не придумывать искусственный язык, чтобы заставлять на нём всех общаться, а идти на поводу у естесственного общения и придумывать названия для папочек и репозиториев такие, какими их называют люди между собой.
В одном проекте мы назвали сущность, которую пользователь через интерфейс запрашивал у менеджера и заполнял поля «Request». Вроде бы логично, пока не оказалось, что в фреймворке был баг и в некоторых случаях глобально доступная переменная внутри языка шаблонов «request» возвращала экземпляр http-запроса, а не нашу локальную переменную request = Request.find(params[:id]). Пришлось придумывать синоним Demand и менять внутреннюю терминологию. Для душнил уточню, что в интерфейсе для пользователя, конечно же, остался request 🙂 С тех пор я стараюсь избегать общих терминов и слов, которые можно было бы трактовать двояко.
В другом проекте было несколько ролей пользователя со своими интерфейсами. Ну, скажем, ORM-модели назывались стандартно User, Project и Company, а вот неймспейсы для каждого пользователя тогдашний архитектор назвал Egg, Chicken и Ranch, подразумевая, что в Ranch можно создать себе Chicken, а в курице — яйцо. Преимущество перед UserApp было огромным, потому как поиск файлов с префиксом egg прятал то, чего не хотелось видеть. Да и интуитивно понятно что из себя представляло каждое из приложений.
А третий пример про особого вида микросервисы в ещё одном проекте, где мы себе придумали такие микросервисы, которых и пристрелить было не жалко и запускать можно было бы когда угодно. Ну, умирали они часто, ну и хрен бы с ними. Там и другие микросервисы были разные, важные и ответственные, но вот эти вот были на особом счету и с особой структурой работы с ними. Назвали мы их сначала «быстродохнущими микросервисами», а потом кто-то назвал их «Леммингами» и оно прижилось так хорошо, что стало префиксом в названии каждого такого микросервиса. Ну, там «lemming_auto_subscription» или «lemming_story_history».
Короче, нельзя придумывать названия просто так. Этимология любого названия обязательно должна быть.
Личным сообщением читатели (много читателей) подсказывают, что в основной айосный телеграм тоже добавили ночную тему. Так что это не повод переходить на «X». Возможно, судя по названию, владельцы последних-распоследних айфонов могут какое-то улучшение нового телеграма увидеть. Но это не точно.
А так в X-телеграме много полезных фич еще не имплементировали. Например геолокация в реальном времени еще отсутствует, количество непрочитанных сообщений пропадает далеко не сразу после прочтения с другого устройства, сохранение напечатанного текста работает не всегда. В общем, любители бета-версий должны быть довольны новым телеграмом. А я себе старый вернул. Что же до десктопной версии под макось, то там все стабильно — кроссплатформенное чудище и нативная красавица.
Ну не даются новостные заметки Экстраполяции, что тут поделаешь! Стоит отложить пост на пару дней, так уже старье, боян и уже неправда. Может, пригласить внештатного редактора для новостных заметок (🗣) или ну их к чертям, эти новости (😈)?
Количество поздравлений с наступившим годом от телеграм-каналов просто умопомрачительное. Читать я их перестал где-то после третьего. А «Экстраполяция» от большинства каналов отличается тем, что очень любит и ценит вас, чтобы по-просту спамить бесполезным сообщениями или рекламой, например.
Так что, во-первых с Новым Годом вас, друзья мои. 🎄
А во-вторых — полезная ссылка. Можно сказать, свежачок с анализом современного джаваскрипта, сделанного на основе опроса разработчиков.
«Джаваскрипт ты можешь не любить, но уважать его обязан», как сказал классик.
https://medium.freecodecamp.org/i-just-asked-23-000-developers-what-they-think-of-javascript-heres-what-i-learned-9a06b61998fa
Дополнение к прошлому посту.
Короче, картинок было две — логотип рубрики и иллюстрация к тексту. Опубликовалась один логотип. По всей видимости, добавить две картинки к посту нельзя. Исправляюсь отдельным постом.
Ну, а чтобы не постить картинку просто так, опубликую еще шикарный присланный отзыв личным сообщением от читателя. Поддержите лайком, пусть будут больше таких вот личных сообщений!
Сейчас пишу кастомные селекты.
В том, который «мульти», еще пытался делать нормальную работу с клавиатурой, а в самом обычном просто забил. Если пытаться повторять поведение нативного, то можно потратить неделю, а див с текстом и второй див с выпадающим списком никто никогда в неделю не оценивает. Но еще ты забыл про кастомные селекты на мобильных девайсах. Это отдельная боль для пользователя, а нативные селекты вообще ни на что не похожи, взять те же айосные барабаны. Ну и понятное дело пользователь очень плохо будет воспринимать кастомное дизайнерское говно.
А еще интересна идея эволюции нативных контролов, взять те же скроллбары. Раньше библиотек, реализующих кастомные скроллы, был вагон и маленькая тележка. И если в то время дизайнер не устоял бы перед искушением добавить немного красоты в его детище, то сейчас его скролл, каким бы крутым он ни был в то время, будет смотреться довольно уныло на фоне аккуратных, иногда даже самоустраняющихся при пассивном состоянии нативных скроллов. Конечно ни один дизайн не живет так долго, но все-равно круто всегда держать в голове возможность эволюции браузеров при проектировании дизайна.
Разработчик должен многое уметь и многое знать, постоянно развиваться. И именно поэтому фронтенд-девелопера стоит переименовать в простого джаваскрипт-разработчика, и ни в коем случае не в react/angular-разработчика. Еще стоит отличать javascript-разработчика от typescript-разработчика, а от elm-разработчика не требовать знать coffeescript. Само собой, разработчик может знать несколько языков, тогда он будет гордо носить титулы, например, typescript-разработчика и elm-разработчика одновременно.
Конечно, тенденции серверной разработки говорят нам, что вполне успешно могут существовать scala-разработчики, которые вообще не умеют писать на java или elixir-разработчики, которые ни в зуб ногой в erlang. И это нормально.
Теперь ограничим это множество с другой стороны. Инструментарных разработчиков, вне зависимости от вероисповедания, вроде django-разработчиков, rails-разработчиками и angular-разработчиками нужно отправлять куда-нибудь учиться, а не программировать. Вместе под руку с операторами фотошопа, администраторов mysql и css-верстальщиками.
Возражение «везде есть свои особенности и костыли, которые надо знать» говорит, что действительно везде свои особенности и все надо, мать его, знать. И никакой фулстековостью или узкой специализацией это решить не получится.
Сегодня, на правах субботнего вечернего поста, хочу высказать свое «фи» современному ИИ. До человеческих способностей ему еще ой как далеко :-)
Читать полностью…
У обычных разработчиков (серверных, если хотите), а не у «фронтенд-разработчиков» с идентификацией все более или менее аккуратно и очевидно. Фраза «я разработчик и я знаю питон, скалу, руби, эрланг и сервера настраивать» никого не удивляет и вполне естественна. А вот «я фронтенд-девелопер и умею все, что в браузере работает», звучит почему-то раздуто.
Еще подмечено, что у крутых нодэджеэсеров считается зазорным уметь хорошо верстать. Но это не точно.
