Если вы чувствуете себя небезопасно или вам стало неудобно работать из-за санкций, и вы хотите переждать неспокойное время в другой стране, мы собрали несколько вариантов временного бюджетного релокейта. Советуем не принимать реактивных решений, а все тщательно продумать.
Король разработки
DynamicData: Изменяющиеся коллекции, шаблон проектирования MVVM и реактивные расширения
В феврале 2019 года состоялся релиз ReactiveUI 9 — кроссплатформенного фреймворка для построения приложений с GUI на платформе Microsoft .NET. ReactiveUI — это инструмент для тесной интеграции реактивных расширений с шаблоном проектирования MVVM. Знакомство с фреймворком можно начать с серии статей на Хабре или со вступительной страницы документации. Обновление ReactiveUI 9 включает в себя множество исправлений и улучшений, но, пожалуй, самое интересное и значимое изменение — тесная интеграция с фреймворком DynamicData, позволяющим работать с изменяющимися коллекциями в реактивном стиле. Попробуем разобраться, в каких случаях нам может пригодиться DynamicData и как устроен внутри этот мощный реактивный фреймворк!
Представьте — что если все, что вы делаете будет бессмысленным и бесполезным?
Пять лет назад я сидел в чужой квартире, в чужом городе, без работы и с последними копейками на счету. За два месяца до этого я ушел из большой корпорации. Мне казалось, я был слишком хорош для того, что в ней делал. Хотел заниматься чем-нибудь полезным, возвышенным и меняющим-мир-к-лучшему — а не увядать и жиреть в корпоративной столовке.
На прощание мне говорили, что я полный идиот, потому что нигде не найду таких же денег в своей профессии, что даже в лучших местах мне будут платить в три раза меньше, а драть в пять раз больше. Я подумал — пускай, я слишком молод, чтобы расслабляться, до тридцатника не помешает хлебнуть профилактического говнеца.
Но пары месяцев с голой задницей оказалось достаточно, чтобы сломаться.
Представьте — вам дали гору денег, но забрали программирование навсегда. Обрадуетесь? Что будете делать?
Моя бабушка пришла работать на фабрику когда ей не было и двадцати. Она ходила к станку каждый день, сорок лет, от звонка до звонка — в прямом смысле. Мой дед — в точности так же — устроился шофером, когда еще был пацаном, и водил свой грузовик каждый день по одному маршруту до самой пенсии. Та же история была у мамы, и была бы у отца — не закрой его завод в 90-е.
Когда я об этом думаю, меня съедает чернющая тоска — я все никак не успеваю стать достаточно богатым, чтобы разорвать порочный круг “работать чтобы есть чтобы дальше работать” и дать им жизнь, которую сам считаю счастливой.
Раньше я был уверен, что должен это сделать, но теперь еще больше запутался. Мне уже не кажется, что они несчастны в своем образе жизни. Они точно работают не ради денег, не ради того, чтобы куда-то вырваться, и никогда не работали только ради этого.
Теперь мне кажется — что это я на самом деле несчастен.
Почему мы выбрали MobX, а не Redux, и как его использовать эффективнее
Меня зовут Назим Гафаров, я разработчик интерфейсов в Mail.ru Cloud Solutions. На дворе 2020 год, а мы продолжаем обсуждать «нововведения» ES6-синтаксиса и преимущества MobX над Redux. Существует много причин использовать Redux в своем проекте, но так как я не знаю ни одной, расскажу о том, почему мы выбрали MobX.
Пока все праздновали мой день рождения, я до утра чинил кластер — а разрабы валили на меня свои ошибки
Вот история, которая навсегда перевернула мой подход к работе девопса. Еще в доковидные времена, задолго-задолго до них, когда мы с парнями только задумывали свое дело и фрилансили на случайных заказах, мне в телегу упало одно предложение.
Компания, которая написала, занималась аналитикой данных. Ежедневно она обрабатывала тысячи запросов. К нам они пришли со словами: ребят, у нас есть ClickHouse и мы хотим автоматизировать его настройку и установку. Хотим Ansible, Terraform, Докер и чтобы это все хранилось в гите. Хотим кластер из четырех нод по две реплики в каждой.
Стандартная просьба, каких десятки, и нужно такое же хорошее стандартное решение. Мы сказали «окей», и через 2-3 недели все было готово. Работу они приняли и начали переезжать на новый кластер Кликхауса с помощью нашей утилиты.
Мы поступили в универ и сами показали преподам, как учить студентов. Теперь собираем самые большие аудитории
Замечали, скажешь человеку слово “универ”, как он сразу погружается в душные воспоминания? Там он тратил свою молодость на бесполезные предметы. Там он получал устаревшие знания, и там обитали преподы, давно слившиеся с учебниками, но ничего не понимающие в современной IT-индустрии.
К чёрту всё: дипломы не важны, а ВУЗы не нужны. Так ведь вы все говорите? Я думаю об этом каждый свой день, и, знаете, я с этим не согласен! В универ стоит поступить. Там есть такие же парни и девчонки с горящими глазами, как и ты, там есть сообщество. И вместе вы сможете сделать много нового. К примеру, альтернативу образовательной программе ВУЗа в своём городе.
В Tarantool можно совместить супербыструю базу данных и приложение для работы с ними. Вот как просто это делается
Ради любопытства я решил вернуться к нему, протестировать последнюю версию — и на этот раз проект мне очень понравился. Сейчас я покажу, как написать в Tarantool простое приложение, нагружу его и проверю производительность, и вы увидите, как там все легко и круто.
Мне было стыдно за свой интерпрайз-код настолько, что я сделал свой велосипед. За него стыдно меньше
Это продолжение текста про архитектуры интерпрайз-систем. Рассуждения это хорошо, но какой в них толк без практического применения. Я покажу свой фреймворк в деле.
Всё началось с того, что я рассказывал про проблематику проектирования приложений на .NET и ныл про нелёгкую жизнь в кровавом интерпрайзе. Затем я описал решение, которое сам придумал и реализовал — Reinforced.Tecture. То была теория, концептуальные рассуждения, визионёрство и снова нытьё. На этот раз о том, что на дворе 2020 год, а HKT в C# так и не завезли.
Сегодня я продемонстрирую свой подход в действии на примере простенького проекта и покажу профиты, которые он даёт: от сокращения количества кода до автоматизации тестирования и оригинального подхода к документации. Как советовал старина Торвальдс: "Болтовня ничего не стоит, покажите мне код".
Пока в вузах преподают люди, которые боятся кода и ненавидят разработку — никакого фундамента и базы мы не получим
Когда новички интересуются, с чего начать изучать программирование, им часто советуют именно вузы — там настоящий computer science, фундаментальные знания и вообще дорога в нормальную жизнь. Не то что надергать в интернете знаний и бежать программировать с умным видом, чтобы потом набивать шишки и позориться перед людьми с «настоящими знаниями».
Я может и не собирался писать код для передовых проектов NASA, но мне хотелось чтобы вуз помог мне научиться вникать в проблемы, которые изо дня в день решают профессиональные программисты. Нужно ли говорить, какую связь с реальностью я увидел в своем вузе? Думаю, все-таки нужно.
В IT растет цензура, а мы не замечаем — разрешают только улыбаться и молчать
У меня есть две статьи-интервью вот с такими странными абзацами. За обоими кроются неприятные истории для меня и для людей, про которых я писал.
Мне надоело, что индустрия зависит от прихоти создателей языков программирования. Сообществу нужно больше власти
Я программирую 16 лет, и перебрал за это время много технических стеков. Изучать языки весело, в начале они всегда как новенькие игрушки, пока месяце на третьем не появляются первые проблемы.
В языках вечно не хватает чего-то простого — лямбда-функций, именованных объединений, кастомных примитивных типов. Я лезу в обсуждения на Stack Overflow, в Github и вижу, как разрабы жалуются — им не хватает того же, чего и мне. Но обсуждения почти всегда заканчиваются одинаково: нужная фича не появится, потому что главный дизайнер языка и члены его команды нужной ее не считают.
Раньше в эти моменты мне казалось, что это я неграмотный, и чего-то не понимаю. Что создатели языков за гранями приземленной разрабовской критики. Они умны, дальновидны, преисполнены мудрости, и пути их неисповедимы.
Но сейчас я понимаю — это полная чушь.
Я десять лет страдал от ужасных архитектур в C# приложениях — и вот нашел, как их исправить
Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.
Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.
Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.
Парсите, а не валидируйте
Еще в декабре мне попалась одна совершенно замечательная статья на английском, посвящённая использованию системы типов языка для более широкого класса задач, для повышения надежности приложений и простоты рефакторинга. К сожалению, в тот момент я был слишком занят написанием статей по ФП, которые крайне важно было написать, пока свежи воспоминания. Но теперь, когда с этой задачей я справился, наконец дошли руки перевести эту замечательную заметку. Оригинальный язык примеров — Хаскель, но я решил переписать их на раст, для более широкого охвата аудитории. Однако язык тут совершенно неважен, советы этой статьи я применяю в ежедневной разработке на вполне себе "приземлённых" C# и TypeScript, так что если вы просто стараетесь писать надёжный и поддерживаемый код, то, вне зависимости от языка, статья вам будет в тему.
Благодарю за вычитку и помощь в переводе Hirrolot, funkill и andreevlex
Тесты на статистическую значимость — это чудовищно ущербный инструмент
Когда я участвовал в продуктовой разработке, меня страшно бесили прагматичные дизайнеры — те, что все пытались делать только на основе статистических исследований.
Вот мне хочется, чтобы кнопка была зеленой, просто потому что мне так больше нравится. А дизайнер говорит — «неважно, АБ-тесты показали, что на кнопку поносного цвета кликают на 0,2% чаще». Господи, дружище, ты десять лет прокачивал свой вкус и опыт, чтобы что? Чтобы наш продукт напоминал птичью какашку? Но бизнес говорит — раз есть цифры, значит мы обмажем этим все.
Я понимаю, люди хотят заработать денег. Они не хотят доверять своей вкусовщине, когда речь идет про удовлетворение толпы. Но теперь я знаю, что проблема может быть не в цифрах, а в людях, которые не умеют пользоваться статистическими тестами.
На прошлой неделе у нас в подкасте был Андрей Акиньшин, кандидат физ-мат наук и специалист в области перформанс-анализа. Он рассказал нам, почему у него тоже бомбит от современной математической статистики.
Если ты видишь статью, что язык Х быстрее, чем язык Y – можешь закрывать статью
Я своими гуманитарными мозгами всегда думал так — если программист знает, как сделать перфоманснее — значит надо сделать перфоманснее. Производительное решение = правильное решение. Один язык программирования может быть медленнее другого, и если это выяснится — язык программирования отправляется на помойку.
Ну и уж точно — если разработчик — специалист в области перфоманса, он будет топить за все эти вещи, даже если они неверны.
Естественно, все это чушь, но не мне вам об этом говорить. Поэтому к нам в подкаст пришел Андрей Акиньшин — разработчик и математик, кандидат физико-математических наук, мейнтейнер BenchmarkDotNet и perfolizer, автор книги Pro .NET Benchmarking и просто очень, очень крутой инженер.
Я мечтал вырваться из Узбекистана и стать крутым разрабом. Больше не хочу — но разработка не отпускает
Я не из тех инженеров, кто в детстве чинил паяльником старый бабушкин телевизор. Папа не покупал мне компьютер. Я вырос в Ташкенте, Узбекистан, жил довольно средне, учился в плохой школе, был ботанистый в младших классах, и особо ни с кем не тусил. Мама работала, старалась заработать денег. Поэтому я в основном жил с бабушкой.
На меня никогда не давили с учебой. Говорили, отучись и иди работай, не важно кем, главное без дела не сиди. Я не сидел — я рубил в игры, прям дико, даже операцию на глаз пришлось делать. Начал зависать в прокуренных клубах, и одобрение пацанов поднял тем, что хорошо играл в варчик. Потом стал деградировать на районе. Среди друзей никогда не было ни одного разработчика — но это мне в них скорее нравится. Никаких клубов по интересам, даже рэпером никто не хотел стать — просто обычные ребята.
Мучают ли Андрея Бреслава ошибки в дизайне Kotlin, которые уже нельзя исправить// Мы обречены #6
Андрей Бреслав почти не говорит про Kotlin в последнее время. Два раза я звал его на интервью, и оба раза он просил не обсуждать технические вопросы.
С одной стороны — мне досадно. Я понимаю, что их задавали все остальные — но я же не задавал. Я, наверное, последний чисто гуманитарный журналист в России, которому хочется рассказывать людям об инженерной стороне индустрии, а не только о поднятых миллионах успешных бизнесменов; и который не будет задавать вот это жалкое “ну объясни моим слушателям на пальцах, как это работает, чтобы они поняли”.
С другой стороны — характеры людей понятны и интересны лично мне больше, чем технологии, и я рад, когда крутой разработчик, готов рассказывать о себе, как о человеке, а не рабочей единице.
Первое интервью я взял у Бреслава год назад, но так его и не выпустил. На второе позвали в подкаст вместе с fillpackart. Он порефлексировал об успехах и ошибках в Kotlin, поборолся с нашими стереотипами о полиамории, выслушал жалобы на жизнь и приложил мощной лекцией с оправданием динамической типизации.
Памятка по работе с Canvas API
Доброго времени суток, друзья!
Данная статья представляет собой небольшую подборку примеров работы с Canvas API, к которой удобно обращаться при необходимости вспомнить изученный материал.
Это не руководство по работе с холстом, а лишь демонстрация его возможностей.
Для меня это также своего рода промежуточный итог в изучении холста.
Код разбит на отдельные блоки-песочницы, которые для удобства чтения помещены под «кат».
Парочка важных моментов.
Ширину и высоту холста лучше определять с помощью атрибутов:
<canvas width="300" height="300"></canvas>
Если мы хотим, чтобы холстом была вся область просмотра, то делаем следующее:
const width = canvas.width = innerWidth
const height = canvas.height = innerHeight
Холст и двумерный контекст рисования я обычно определяю следующим образом:
const canvas = document.querySelector('canvas')
// не путать с объектом jQuery
const $ = canvas.getContext('2d')
Довольно слов.
Ты провалил на собесе один теоретический вопрос, и на тебе поставили крест. Это нормально? // Мы обречены #3
Павел Новиков до 30 лет жил в Новосибирске и работал удаленно, собирая на Upwork заказы со всего мира. Один заказчик остался надолго — Паша строил для него систему почти с нуля, и маленький стартап превращался в огромную фирму. Основатели обещали большую должность, но потом передумали и просто некрасиво уволили.
Снова браться за мелкие заказы с апворка Паша не стал и впервые задумался о релокации. Так он оказался в Минске — там он собирает команду, чтобы открыть локальный офис израильской компании.
Паша пришёл к нам на подкаст, обсудил с нами найм и индустрию и даже устроил что-то вроде показательного собеса (которое пошло не совсем хорошо).
Information
- Rating
- Does not participate
- Location
- Иваново, Ивановская обл., Россия
- Works in
- Date of birth
- Registered
- Activity