Ментор, разработчик, преподаватель
За последние три года ко мне обращалось несколько человек, которые просили научить их программированию. Вспоминая собственный путь, я никому не отказывал и даже не брал за это деньги. Мне хотелось, чтобы люди не страдали как я, поэтому облегчал процесс обучения как мог. По итогу этого опыта, я больше не буду учить программированию. И вот три истории почему.
Несколько недель назад мы с коллегой сделали ChatGPT-proxy бота в Telegram, который помогал в наших рабочих чатах и просто развлекал нас. Он написан на TypeScript и потрясающем фреймворке Grammy, использует Open AI API, а именно модель gpt3.5-turbo, которая используется в оригинальном ChatGPT.
В этой статье мы разберем новые удивительные способности последней языковой модели из семейства GPT (от понимания мемов до программирования), немного покопаемся у нее под капотом, а также попробуем понять – насколько близко искусственный интеллект подошел к черте его безопасного применения?
Покрытие приложения тестами - один из самых важных принципов в разработке. У тестов есть множество безусловных достоинств: они помогают избегать баги, регрессии и экономят много денег.
Во Flutter есть несколько видов написания тестов. Они: Unit-тесты, Widget-тесты и Integration-тесты. Как порядочный разработчик, Flutter приложения вы будете писать вместе с тестами.
Dart Code Metrics — это инструмент статического анализа кода, который позволяет собирать метрики по коду и предоставляет дополнительные правила для анализатора. Основная задача — помогать разработчикам следить за качеством кода и улучшать его. В этой статье мы хотим поделиться возможностями инструмента с сообществом. Он помог нам в Wrike решить часть проблем на фронтенде, и, надеемся, поможет и вам.
Всем добрый день!
Вот и добрались руки до первого поста на Хабре спустя довольно продолжительное количество времени. Согласно высказыванию - мужчина должен построить дом, вырастить сына и посадить дерево, а что же должен преподаватель? Да черт его знает! Но более чем уверен, что там будет пунктик про написание книги. А если эта книга еще и в свободном доступе...
Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.
Речь пойдет о проблемах, с которыми вы можете столкнуться при написании многопоточного кода, если вы думаете, что достаточно умны, чтоб спроектировать свои собственные механизмы синхронизации.
То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.
Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.
У функционального программирования есть одна большая проблема — о нем очень непросто рассказывать. Попытки донести людям что-то с использованием терминов типа «зигохистоморфный препроморфизм» легко сводят неподготовленного слушателя с ума.
Марк Симан — автор популярной книги Dependency Injection in .NET, автор бесчисленных блог-постов. На DotNext 2017 Moscow Марк рассмотрел применение dependency injection в классическом объектно-ориентированном дизайне и объяснил, почему его необязательно (даже нежелательно) использовать в функциональном программировании. Следом за этим он наглядно показал, как использование приемов функционального программирования устраняет необходимость в использовании моков и стабов в модульном тестировании и позволяет полностью выбросить мусор из прямого перечисления зависимостей.
Под катом — перевод доклада и видео. Далее повествование будет от лица Марка.
Привет, Хаброжители! Мы издали книгу для мальчиков и девочек. Что такое Roblox? Это красочная компьютерная платформа для создания и публикации своих игр. Мир Roblox изо дня в день становится все популярней, и ты можешь стать его частью!
Эта шпаргалка поможет вам подготовиться к техническому собеседованию, чтобы вы могли освежить в памяти ключевые вещи. По сути, это содержание курса по информатике безо всяких подробностей.
Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?
Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.
Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.
Я решил начать с буквы O, так как принцип открытости-закрытости, по сути, является центральным. Среди прочего тут есть много важных тонкостей, на которые стоит обратить внимание:
Привет, Хабр!
В прошлой статье меня знатно разбомбили в комментариях, где-то за дело, где-то я считаю, что нет. Так или иначе, я выжил, и у меня есть чем с вами поделиться >:)
Напомню, что в той статье я рассказывал, каким я вижу идеальное собеседование и что я нашёл компанию, которая так и делает - и я туда прошёл, хотя это был адский отбор. Я, довольный как слон, везде отметил, что я не ищу работу, отовсюду удалился и стал работать работу.
Как вы думаете, что делают рекрутеры, когда видят "Alexandr, NOT OPEN FOR WORK"? Правильно, пишут "Алексей, рассматриваете вариант работать в X?" Я обычно игнорирую это, но тут мне предложили попытать счастья с Яндекс.Лавкой, и я не смог пройти мимо - интересно было, смогу ли я устроиться куда-нибудь, когда введут великий российский файерволл. К тому же за последние 3 года я проходил только два интервью, и мне показалось, что я не в теме, что нынче требуется индустрии. Блин, я оказался и вправду не в теме. И вы, скорей всего, тоже - об этом и статья.
